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Sunny 在 CSDN 技 术 博 客 中 陆续 发 表 了 100 多 篇 与 设计 模式 学 习 相 关 的 文章 ， 涵 盖 了 七 个 面向 对 
象 设 计 原 则 和 24 个 设计 模式 (23 个 GoF 设 计 模 式 + 简单 工厂 模式 ) ， 为 了 方便 大 家 学 

习 ，http://quanke.name 现 将 所 有 文章 的 进行 了 整理 ， 方 便 大 家 下 载 阅 读 ， 硕 望 能 给 各 位 带 来 帮 
助 ! 





阅读 地 址 : http:/gof.quanke.name/ 


下 载 地 址 : https:/www.gitbook.com/book/guanke/design-pattern-java/ 





源码 下 载 地 址 : https://github.com/quanke/design-pattern-java-source-code.git 
课件 下 载 地 址 : http://www.chinasa.info/download/DP-Slides.rar 

作者 : 刘 伟 http://blog.csdn.net/lovelion 
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关于 金良 小 说 中 到 底 是 招式 重要 还 是 内 功 重要 的 争论 从 未 停止 ， 我 们 在 这 里 并 不 分 析 张 无 忌 

的 九 阳 神功 和 令狐冲 的 独孤 九 剑 到 底 哪个 更 厉害 ， 但 我 想 每 个 武林 人 士 梦 呈 以 求 的 应 该 是 既 
有 淋 注 的 招式 又 有 深厚 的 内 功 。 看 到 这 里 大 家 可 能 会 产生 疑问 了 ? 摘 什 么 ， 讨 论 什 么 招式 与 

内 功 ， 我 只 是 个 软件 开发 人 员 。 别 急 ， 正 因为 你 是 软件 开发 人 员 我 才 跟 你 谈 这 个 ， 因 为 我 们 

的 软件 开发 技术 也 包括 一 些 招 式 和 内 功 : Java、C#、C++ 等 编程 语言 ，Eclipse、Visual Studio 
等 开发 工具 ，JSP、ASPnet 等 开发 技术 ，Struts、Hibernate、JBPM 等 框架 技术 ， 所 有 这 些 我 们 
都 可 以 认为 是 招式 ; 而 数据 结构 、 算 法 、 设 计 模 式 、 重 构 、 软 件 工 程 等 则 为 内 功 。 招 式 可 以 

很 快 学 会 ， 但 是 内 功 的 修炼 需要 更 长 的 时 间 。 我 想 每 一 位 软件 开发 人 员 也 都 希望 成 为 一 名 兼 
具 淋 注 招 式 和 深厚 内 功 的 <“ 上乘? 软件 工程 师 ， 而 对 设计 模式 的 学 习 与 领悟 将 会 让 你 “内 功 ” 大 

增 ， 再 结合 你 日 益 纯熟 的 “招式 ”， 你 的 软件 开发 “功力 ”一 定 会 达到 一 个 新 的 境界 。 既 然 这 样 ， 
还 等 什么 ， 赶 快 行动 吧 。 下 面 就 让 我 们 正式 路 上 神奇 而 又 美妙 的 设计 模式 之 旅 。 


A | "at ern 1 angUuage 





1 设计 模式 从 何 而 来 


在 介绍 设计 模式 的 起 源 之 前 ， 我 们 先 要 了 解 一 下 模式 的 诞生 与 发 展 。 与 很 多 软件 工程 技术 一 
样 ， 模 式 起 源 于 建筑 领域 ， 毕 竞 与 只 有 几 十 年 历史 的 软件 工程 相 比 ， 已 经 拥有 几 千 年 沉淀 的 
建筑 工程 有 太 多 值得 学 习 和 借鉴 的 地 方 。 


那么 模式 是 如 何 诞生 的 ?让 我 们 先 来 认识 一 个 人 一 “Christopher Alexander (克里斯托弗 . 亚 历 
山大 ) ， 哈 佛 大 学 建筑 学 博士 、 美 国 加 州 大 学 伯克利 分 校 建筑 学 教授 、 加 州 大 学 伯克利 分 校 
环境 结构 研究 所 所 长 、 美 国 艺 术 和 科学 院 院士 ...... 头衔 监 多 ， 微 笑 ， 不 过 他 还 有 一 个 “上 昵 

称 ” 一 模式 之 父 (The father of patterns)。Christopher Alexander 博 士 及 其 研究 团队 用 了 约 20 年 的 
时 间 ， 对 住宅 和 周边 环境 进行 了 大 量 的 调查 研究 和 资料 收集 工作 ， 发 现 人 们 对 舒适 住宅 和 城 
市 环境 存在 一 些 共 同 的 认同 规律 ，Christopher Alexander 在 著作 A Pattern Language: Towns， 
Buildings, Construction 中 把 这 些 认同 规律 归纳 为 253 个 模式 ， 对 每 一 个 模式 (Pattern) 都 从 
Context (前 提 条 件 ) 、Theme 或 Problem (目标 问题 ) 、Solution (解决 方案 ) 三 个 方面 进行 

了 描述 ， 并 给 出 了 从 用 户 需 求 分 析 到 建筑 环境 结构 设计 直至 经 典 实 例 的 过 程 模型 。 





在 Christopher Alexander 的 另 一 部 经 典 著作 《建筑 的 永恒 之 道 》 中 ， 他 给 出 了 关于 模式 的 定 
义 ，: 


每 个 模式 都 描述 了 一 个 在 我 们 的 环境 中 不 断 出 现 的 问题 ， 然 后 描述 了 该 问题 的 解决 方案 的 核 
心 ， 通 过 这 种 方式 ， 我 们 可 以 无 数 次 地 重用 那些 已 有 的 成 功 的 解决 方案 ， 无 须 再 重复 相同 的 
工作 。 这 个 定义 可 以 简单 地 用 一 句 话 表示 : 
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从 招式 与 内 功 谈 起 一 设计 模式 概述 (一 ) 





模式 是 在 特定 环境 下 人 们 解决 某 类 重复 出 现 问题 的 一 套 成 功 或 有 效 的 解决 方案 。【A pattern is 


a successful or efficient solution to a recurring problem within a context 】 


1990 年 ， 软 件 工程 界 开 始 关注 ChristopherAlexander 等 在 这 一 住宅 、 公 共 建 筑 与 城市 规划 领域 的 
重大 突破 。 最 早 将 模式 的 思想 引入 软件 工程 方法 学 的 是 1991-1992 年 以 “四 人 组 (Gang of Four ， 
简称 GoF， 分 别 是 Erich Gamma, Richard Helm, Ralph Johnson 和 John Vlissides)” 自 称 的 四 位 著名 
软件 工程 学 者 ， 他 们 在 1994 年 归纳 发 表 了 23 种 在 软件 开发 中 使 用 频率 较 高 的 设计 模式 ， 旨 在 
用 模式 来 统一 沟通 面向 对 象 方法 在 分 析 、 设 计 和 实现 间 的 鸿沟 。 


GoF 将 模式 的 概念 引入 软件 工程 领域 ， 这 标志 着 软件 模式 的 诞生 。 软 件 模式 (Software Patterns) 
是 将 模式 的 一 般 概 您 应 用 于 软件 开发 领域 ， 即 软件 开发 的 总 体 指导 思路 或 参照 样板 。 软 件 模 
式 并 非 仅 限于 设计 模式 ， 还 包括 架构 模式 、 分 析 模 式 和 过 程 模 式 等 ， 实 际 上 ， 在 软件 开发 生 
命 周 期 的 每 一 个 阶段 都 存在 着 一 些 被 认同 的 模式 。 


软件 模式 是 在 软件 开发 中 茶 些 可 重 现 问 题 的 一 些 有 效 解决 方法 ， 软 件 模式 的 基础 结构 主要 由 


四 部 分 构成 ， 包 括 问题 描述 【 待 解 决 的 问题 是 什么 】、 前 提 条 件 【 在 何 种 环境 或 约束 条 件 下 
使 用 】、 解 法 【如 何 解决 】 和 效果 【有 哪些 优 缺点 】， 如 图 1-1 所 示 : 


问题 描述 
前 提 条 件 














其 他 相关 模式 






图 1-1 软件 模式 基本 结构 


软件 模式 与 具体 的 应 用 领域 无 关 ， 也 就 是 说 无 论 你 从 事 的 是 移动 应 用 开发 、 桌 面 应 用 开发 、 
Web 应 用 开发 还 是 诅 入 式 软 件 的 开发 ， 都 可 以 使 用 软件 模式 。 


在 软件 模式 中 ， 设 计 模 式 是 研究 最 为 深入 的 分 支 ， 设 计 模 式 用 于 在 特定 的 条 件 下 为 一 些 重 复 
出 现 的 软件 设计 问题 提供 合理 的 ~、 有效 的 解决 方案 ， 它 融合 了 众多 专家 的 设计 经 验 ， 已 经 在 
成 千 上 万 的 软件 中 得 以 应 用 。 1995 年 ，GoF 将 收集 和 整理 好 的 23 种 设计 模式 汇编 成 Design 
Patterns: Elements of Reusable Object-Oriented Software【 《设计 模式 : 可 复 用 面向 对 象 软 件 的 
基础 》】 一 书 ， 该 书 的 出 版 也 标志 着 设计 模式 正式 成 为 面向 对 象 (Object Oriented) 软 件 工 程 的 
一 个 重要 研究 分 支 。 
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从 招式 与 内 功 谈 起 一 设计 模式 概述 (一 ) 





Design Patterns 
Elements of Reusable 
Object-Orierited Software 


Erich Gamma 
Richard Hlelm 
Ralph Johnson 
john Wissides 





从 1995 年 至 今 ， 无 论 是 在 大 型 API 或 框架 (如 JDK、.net Framework 等 ) 、 轻 量 级 框架 (如 
Struts、Spring、Hibernate、JUnit 等 ) 、 还 是 应 用 软件 的 开发 中 ， 设 计 模 式 都 得 到 了 广泛 的 应 
用 。 如 果 你 正在 从 事 面 向 对 象 开发 或 正 准 备 从 事 面 向 对 象 开 发 ， 无 论 你 是 使 用 Java、C#、 
Objective-C、VB.net、Smalltalk 等 纯 面 向 对 象 编 程 语言 ， 还 是 使 用 C++、PHP、Delphi、 
JavaScript 等 可 支持 面向 对 象 编 程 的 语言 ， 如 果 你 一 点 设计 模式 也 不 懂 ， 我 可 以 毫 不 夸张 的 
说 : 你 丨 的 out 了 。 
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从 招式 与 内 功 谈 起 设计 模式 概述 (二) 





从 招式 与 内 功 谈 起 一 设计 模式 概述 (二 ) 
从 招式 与 内 功 谈 起 一 设计 模式 概述 (二 ) 


1.2 设计 模式 是 什么 


俗话 说 : 站 在 别人 的 肩膀 上 ， 我 们 会 看 得 更 远 。 设 计 模 式 的 出 现 可 以 让 我 们 站 在 前 人 的 肩膀 
上 ， 通 过 一 些 成 熟 的 设计 方案 来 指导 新 项 目的 开发 和 设计 ， 以 便于 我 们 开发 出 具有 更 好 的 灵 
活性 和 可 扩展 性 ， 也 更 易于 复 用 的 软件 系统 。 


设计 模式 的 一 般 定 义 如 下 : 设计 模式 (Design Pattern) 是 一 套 被 反复 使 用 、 多 数 人 知晓 的 、 经 过 
分 类 编目 的 、 代 码 设 计 经 验 的 总 结 ， 使 用 设计 模式 是 为 了 可 重用 代码 、 让 代码 更 容易 被 他 人 
理解 并 且 保 证 代码 可 靠 性 。 


狭义 的 设计 模式 是 指 GoF 在 《设计 模式 : 可 复 用 面向 对 象 软件 的 基础 》 一 书 中 所 介绍 的 23 种 经 
典 设 计 模 式 ， 不 过 设计 模式 并 不 仅仅 只 有 这 23 种 ， 随 着 软件 开发 技术 的 发 展 ， 越 来 越 多 的 新 
模式 不 断 诞生 并 得 以 应 用 。 


设计 模式 一 般 包含 模式 名 称 、 问 题 、 目 的 、 解 决 方案 、 效 果 等 组 成 要 素 ， 其 中 关键 要 素 是 模 
式 名 称 、 问 题 、 解 决 方案 和 效果 。 模 式 名 称 (Pattern Name) 通 过 一 两 个 词 来 描述 模式 的 问题 、 
解决 方案 和 效果 ， 以 便 更 好 地 理解 模式 并 方便 开发 人 员 之 间 的 交流 ， 绝 大 多 数 模式 都 是 根据 
其 功能 或 模式 结构 来 命名 的 《GoF 设 计 模式 中 没有 一 个 模式 用 人 名 命名 ， 微 笑 ) ; 问题 
(Problem) 描 述 了 应 该 在 何 时 使 用 模式 ， 它 包含 了 设计 中 存在 的 问题 以 及 问题 存在 的 原因 ; 解 
决 方案 (Solution) 描 述 了 一 个 设计 模式 的 组 成 成 分 ， 以 及 这 些 组 成 成 分 之 间 的 相互 关系 ， 各 自 
的 职责 和 协作 方式 ， 通 常 解决 方案 通过 UML 类 图 和 核心 代码 来 进行 描述 ; 效果 (Consequences) 
描述 了 模式 的 优 缺点 以 及 在 使 用 模式 时 应 权衡 的 问题 。 


虽然 GoF 设 计 模 式 只 有 23 个 ， 但 是 它们 各 有 具 特 色 ， 每 个 模式 都 为 某 一 个 可 重复 的 设计 问题 提供 
了 一 套 解 决 方案 。 根 据 它们 的 用 途 ， 设 计 模 式 可 分 为 创建 型 (Creational)， 结 构 型 (Structural) 和 
行为 型 (Behavioral) 三 种 ， 其 中 创建 型 模式 主要 用 于 描述 如 何 创建 对 象 ， 结 构 型 模式 主要 用 于 
描述 如 何 实现 类 或 对 象 的 组 合 ， 行 为 型 模式 主要 用 于 描述 类 或 对 但 怎样 交互 以 及 怎样 分 配 职 
责 ， 在 GoF 23 种 设计 模式 中 包含 5 种 创建 型 设计 模式 、7 种 结构 型 设计 模式 和 11 种 行为 型 设计 
模式 。 此 外 ， 根 据 某 个 模式 主要 是 用 于 处 理 类 之 间 的 关系 还 是 对 象 之 间 的 关系 ， 设 计 模 式 还 
可 以 分 为 类 模式 和 对 象 模 式 。 我 们 经 常 将 两 种 分 类 方式 结合 使 用 ， 如 单 例 模式 是 对 象 创建 型 
模式 ， 模 板 方法 模式 是 类 行为 型 模式 。 

值得 一 提 的 是 ， 有 一 个 设计 模式 虽然 不 属于 GoF 23 种 设计 模式 ， 但 一 般 在 介绍 设计 模式 时 都 
会 对 它 进行 说 明 ， 它 就 是 简单 工厂 模式 ， 也 许 是 太 “ 简 单 ” 了 ，GoF 并 没有 把 它 写 到 那 本 经 典 著 
作 中 ， 不 过 现在 大 部 分 的 设计 模式 书籍 都 会 对 它 进 行 专 门 的 介绍 。 

表 1 列 出 将 要 介绍 的 24 种 设计 模式 ， 其 中 模式 的 学 习 难 度 是 我 个 人 在 多 年 模式 使 用 和 推广 过 程 
中 的 经 验 总 结 ， 仅 作 参 考 ， 模 式 的 使 用 频率 来 自 著 名 的 模式 推广 和 教育 网 站 
http:/www.dofactory.net 。 


表 1 常用 设计 模式 一 览 表 





类 型 模式 名 称 学 习 难 度 使 用 频率 
| | 档 式 1 
创建 型 模式 Creational 单 例 模 式 Singleton Pattern 友 交 交 交 六 妇女 妈妈 六 


Pattern 


1 | 模 = | 和 人 。 
创建 型 模式 Creational 简单 工厂 模式 Simple Factory Pattern 。 次 克 六 六 六 让 契 友 六 六 
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Pattern 


创建 型 模式 Creational 
Pattern 
创建 型 模式 Creational 
Pattern 
创建 型 模式 Creational 
Pattern 
创建 型 模式 Creational 
Pattern 





结构 型 模式 Structural Pattern 
结构 型 模式 Structural Pattern 
结构 型 模式 Structural Pattern 
结构 型 模式 Structural Pattern 
结构 型 模式 Structural Pattern 
结构 型 模式 Structural Pattern 
结构 型 模式 Structural Pattern 


行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
行为 型 模式 Behavioral 
Pattern 
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设计 模式 概述 (二) 


简单 工厂 模式 Simple Factory Pattern 


工厂 方法 模式 Factory Method Pattern 
抽象 工厂 模式 Abstract Factory Pattern 
原型 模式 Prototype Pattern 


建造 者 模式 Builder Pattern 


适配器 模式 Adapter Pattern 
桥接 模式 Bridge Pattern 

组 合 模式 Composite Pattern 

装饰 模式 Decorator Pattern 
外 观 模式 Facade Pattern 

享 元 模式 Flyweight Pattern 
代理 模式 Proxy Pattern 

职责 链 模 式 Chain of Responsibility 
Pattern 
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命令 模式 Command Pattern 
解释 器 模式 Interpreter Pattern 
迭代 器 模式 Iterator Pattern 
中 介 者 模式 Mediator Pattern 
备忘录 模式 Memento Pattern 
观察 者 模式 Observer Pattern 
状态 模式 State Pattern 
策略 模式 Strategy Pattern 
模板 方法 模式 Template Method Pattern 


访问 者 模式 Visitor Pattern 


女友 六 六 认真 妇女 六 六 


太太 次 六 六 丰 女 女真 女 


六 六 六 克 六 六 友 六 交大 


六 交友 六 六 友 克 六 立交 


女友 女友 女友 六 六 六 


女友 六 六 认真 妇女 让 六 
女友 妇 六 认真 妇女 六 六 
六 六 克 交 六 妇女 女友 六 
六 交友 交 六 妇女 女 六 六 
友信 六 闪闪 友 克 太太 友 
女友 女友 六 克 六 立交 交 
太太 克 交 六 契 女 女友 六 


太太 友 交 六 友 克 六 次 次 


六 交友 六 六 友 克 太太 次 


女友 女友 女 女 六 六 六 六 


女友 女 六 六 契 女 女 太 女 


友 丰 女 六 六 丰 女 六 六 六 


交友 次 交 立 真 丰 闪闪 六 


女友 女 六 六 丰 女 女 太 女 


六 交友 交 六 妇女 女 六 六 


友 六 闪闪 认 真 丰 契 让 六 


女友 六 闪闪 真 契 女 六 六 


交友 交友 六 友 六 六 六 六 
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从 招式 与 内 功 谈 起 一 设计 模式 概述 (三 ) 


1.3 设计 模式 有 什么 用 


下 面 我 们 来 回答 最 后 一 个 问题 : 设计 模式 到 底 有 什么 用 ? 简单 来 说 ， 设 计 模 式 至 少 有 如 下 几 
个 用 途 : 


(1) 设计 模式 来 源 众 多 专家 的 经 验 和 智慧 ， 它 们 是 从 许多 优秀 的 软件 系统 中 总 结 出 的 成 功 的 、 
能 够 实现 可 维护 性 复 用 的 设计 方案 ， 使 用 这 些 方案 将 可 以 让 我 们 避免 做 一 些 重复 性 的 工作 ， 

也 许 我 们 冥 思 苦 想 得 到 的 一 个 “ 自 以 为 很 了 不 起 ”的 设计 方案 其 实 就 是 菜 一 个 设计 模式 。 在 时 间 
就 是 金钱 的 今天 ， 设 计 模 式 无 疑 会 为 有 助 于 我 们 提高 开发 和 设计 效率 ， 但 它 不 保证 一 定 会 提 
高 ， 微 笑 。 


(2) 设计 模式 提供 了 一 套 通 用 的 设计 词汇 和 一 种 通用 的 形式 来 方便 开发 人 员 之 间 沟 通 和 交流 ， 
使 得 设计 方案 更 加 通俗 易 懂 。 交 流通 常 很 耗 时 ， 任 何 有 助 于 提高 交流 效率 的 东西 都 可 以 为 我 
们 节省 不 少时 间 。 无 论 你 使 用 哪 种 编程 语言 ， 做 什么 类 型 的 项 目 ， 甚 至 你 处 于 一 个 国际 化 的 
开发 团队 ， 当 面 对 同一 个 设计 模式 时 ， 你 和 别人 的 理解 并 无 二 异 ， 因 为 设计 模式 是 跨 语言 、 
跨 平台 、 跨 应 用 、 跨 国界 的 ， 微 笑 。 


(3) 大 部 分 设计 模式 都 兼顾 了 系统 的 可 重用 性 和 可 扩展 性 ， 这 使 得 我 们 可 以 更 好 地 重用 一 些 已 
有 的 设计 方案 、 功 能 模块 甚至 一 个 完整 的 软件 系统 ， 避 免 我 们 经 常 做 一 些 重复 的 设计 、 编 写 
一 些 重 复 的 代码 。 此 外 ， 随 着 软件 规模 的 日 益 增 大 ， 软 件 寿 命 的 日 益 变 长 ， 系 统 的 可 维护 性 
和 可 扩展 性 也 越 来 越 重要 ， 许 多 设计 模式 将 有 助 于 提高 系统 的 灵活 性 和 可 扩展 性 ， 让 我 们 在 
不 修改 或 者 少 修 改 现 有 系统 的 基础 上 增加 、 删 除 或 者 替换 功能 模块 。 如 果 一 点 设计 模式 都 不 
懂 ， 我 想 要 做 到 这 一 点 恐怕 还 是 很 困难 的 ， 微 笑 。 (4) 合理 使 用 设计 模式 并 对 设计 模式 的 使 用 
情况 进行 文档 化 ， 将 有 助 于 别人 更 快 地 理解 系统 。 如 果 某 一 天 因为 升 职 或 跳槽 等 原因 ， 别 人 
接手 了 你 的 项 目 ， 只 要 他 也 懂 设计 模式 ， 我 想 他 应 该 能 够 很 快 理解 你 的 设计 思路 和 实现 方 

案 ， 让 你 升 职 无 后 患 之 忧 ， 跳 槽 也 心安 理 得 ， 何 乐 而 不 为 呢 ? 微笑 。 (5) 最 后 一 点 对 初学 者 很 
重要 ， 学 习 设 计 模 式 将 有 助 于 初学 者 更 加 深入 地 理解 面向 对 象 思 想 ， 让 你 知道 : 如 何 将 代码 
分 散在 几 个 不 同 的 类 中 ?为 什么 要 有 “接口 ?? 何谓 针对 抽象 编程 ? 何 时 不 应 该 使 用 继承 ? 如 果 
不 修改 源 代码 增加 新 功能 ? 同时 还 让 你 能 够 更 好 地 阅读 和 理解 现 有 类 库 (如 JDK) 与 其 他 系统 
中 的 源 代码 ， 让 你 早点 脱离 面向 对 象 编 程 的 “菜鸟 期 ”， 微 笑 。 


1.4 个 人 观点 


作为 设计 模式 的 忠实 粉丝 和 推广 人 员 ， 在 正式 学 习 设 计 模式 之 前 ， 我 结合 多 年 的 模式 应 用 和 
教育 培训 经 验 与 大 家 分 享 几 点 个 人 的 看 法 ， 以 作 参 考 : 


(1) 掌握 设计 模式 并 不 是 件 很 难 的 事情 ， 关 键 在 于 多 思考 ， 多 实践 ， 不 要 听 到 人 家 说 懂 几 个 设 
计 模 式 就 很 " 牛 "， 只 要 用 心 学 习 ， 设 计 模式 也 就 那么 回 事 ， 你 也 可 以 很 “ 牛 " 的 ， 一 定 要 有 信 
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(2) 在 学 习 每 一 个 设计 模式 时 至 少 应 该 掌握 如 下 几 点 : 这 个 设计 模式 的 意图 是 什么 ， 它 要 解决 
一 个 什么 问题 ， 什 么 时 候 可 以 使 用 它 ; 它 是 如 何 解 决 的 ， 掌 握 它 的 结构 图 ， 记 住 它 的 关键 代 
码 ; 能 够 想到 至 少 两 个 它 的 应 用 实例 ， 一 个 生活 中 的 ， 一 个 软件 中 的 ; 这 个 模式 的 优 缺 点 是 
什么 ， 在 使 用 时 要 注意 什么 。 当 你 能 够 回答 上 述 所 有 问题 时 ， 茶 喜 你 ， 你 了 解 一 个 设计 模式 
了 ， 至 于 掌握 它 ， 那 就 在 开发 中 去 使 用 吧 ， 用 多 了 你 自然 就 掌握 了 。 
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从 招式 与 内 功 谈 起 一 一 设计 模式 概述 (三 ) 


(3) “如 果 想 体验 一 下 运用 模式 的 感觉 ， 那 么 最 好 的 方法 就 是 运用 它们 ”。 正 如 在 本 章 最 开始 所 
说 的 ， 设 计 模式 是 “内 功 心 法 ”， 它 还 是 要 与 "实战 招式 * 相 结合 才能 够 相得益彰 。 学 习 设计 模式 
的 目的 在 于 应 用 ， 如 果 不 懂 如 何 使 用 一 个 设计 模式 ， 而 只 是 学 过 ， 能 够 说 出 它 的 用 途 ， 绘 制 
它 的 结构 ， 充 其 量 也 只 能 说 你 了 解 这 个 模式 ， 严 格 一 点 说 : 不 会 在 开发 中 灵活 运用 一 个 模式 
基本 上 等 于 没 学 。 所 以 一 定 要 做 到 : 少 说 多 做 。 


(4) 千 万 不 要 滥用 模式 ， 不 要 试图 在 一 个 系统 中 用 上 所 有 的 模式 ， 也 许 有 这 样 的 系统 ， 但 至 少 
目前 我 没有 碰 到 过 。 每 个 模式 都 有 自己 的 适用 场景 ， 不 能 为 了 使 用 模式 而 使 用 模式 ? 【怎么 
理解 ， 大 家 自己 思考 ， 微 笑 】， 滥 用 模式 不 如 不 用 模式 ， 因 为 滥用 的 结果 得 不 到 “艺术 品 ” 一 样 
的 软件 ， 很 有 可 能 是 一 堆 垃圾 代码 。 


(5) 如 果 将 设计 模式 比喻 成 “< 三 十 六 计 ”， 那么 每 一 个 模式 部 是 一 种 计策 ， 它 为 解决 某 一 类 问题 
而 诞生 ， 不 管 这 个 设计 模式 的 难度 如 何 ， 使 用 频率 高 不 商 ， 我 建议 大 家 都 应 该 好 好 学 学 ， 多 

学 一 个 模式 也 就 意味 着 你 多 了 "一 计 ”， 说 不 定 什么 时 候 一 不 小 心 就 用 上 了 ， 微 笑 。 因 此， 模式 
学 习 之 路 上 要 不 怕 困 难 ， 勇 于 挑战 ， 有 的 模式 虽然 难 一 点 ， 但 反复 琢磨 ， 反 复 研读 ， 应 该 还 

是 能 够 征服 的 。 


(6) 设计 模式 的 “上乘” 境界 : “手中 无 模式 ， 心 中 有 模式 ”。 模 式 使 用 的 最 高 境界 是 你 已 经 不 知 
道具 体 某 个 设计 模式 的 定义 和 结构 了 ， 但 你 会 灵活 自如 地 选择 一 种 设计 方案 【其 实 就 是 某 个 
设计 模式 】 来 解决 菜 个 问题 ， 设 计 模式 已 经 成 为 你 开发 技能 的 一 部 分 ， 能 够 手 到 擒 来 ，“ 内 
功 ” 与 “招式 ”已 浑然 一 体 ， 要 达到 这 个 境界 并 不 是 看 完 某 本 书 或 者 开发 一 两 个 项 目 就 能 够 实现 
的 ， 它 需要 不 断 沉 淀 与 积累 ， 所 以 ， 对 模式 的 学 习 不 要 急于 求 成 。 


(7) 最 后 一 点 来 自 GoF 已 故 成 员 、 我 个 人 最 尊 效 和 党 和 拜 的 软件 工程 大 师 之 一 John Vlissides 的 著 
作 《 设 计 模 式 沉 思 录 》(Pattern Hatching Design Patterns Applied) : 模式 从 不 保证 任何 东西 ， 它 
不 能 保证 你 一 定 能 够 做 出 可 复 用 的 软件 ， 提 高 你 的 生产 举 ， 更 不 能 保证 世界 和 平 ， 微 笑 。 模 
式 并 不 能 替代 人 来 完成 软件 系统 的 创造 ， 它们 只 不 过 会 给 那些 缺乏 经 验 但 却 具备 才能 和 创造 
力 的 人 带 来 希望 。 


扩展 John Vlissides (1961-2005) ，GoF 成 员 ， 斯 坦 福 大 学 计算 机 科学 博士 ， 原 BM 研究 员 ， 


因 患 脑 瘤 于 2005 年 11 月 24 日 (感恩 节 ) 病故 ， 享 年 44 岁 ， 为 纪念 他 的 贡献 ，ACM SIGPLAN 特 
设立 John Vlissides 奖 。 
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面向 对 参 设 计 原 则 
面向 对 畸 设 计 原 则 


对 于 面向 对 象 软件 系统 的 设计 而 言 ， 在 支持 可 维护 性 的 同时 ， 提 高 系统 的 可 复 用 性 是 一 个 至 
关 重 要 的 问题 ， 如 何 同时 提高 一 个 软件 系统 的 可 维护 性 和 可 复 用 性 是 面向 对 象 设计 需要 解决 
的 核心 问题 之 一 。 在 面向 对 象 设计 中 ， 可 维护 性 的 复 用 是 以 设计 原则 为 基础 的 。 每 一 个 原则 
都 草 含 一 些 面向 对 象 设计 的 思想 ， 可 以 从 不 同 的 角度 提升 一 个 软件 结构 的 设计 水 平 。 


面向 对 象 设 计 原 则 为 支持 可 维护 性 复 用 而 诞生 ， 这 些 原 则 绚 含 在 很 多 设计 模式 中 ， 它 们 是 从 
许多 设计 方案 中 总 结 出 的 指导 性 原则 。 面 向 对 象 设计 原则 也 是 我 们 用 于 评价 一 个 设计 模式 的 
使 用 效果 的 重要 指标 之 一 ， 在 设计 模式 的 学 习 中 ， 大 家 经 常会 看 到 诸如 “XXX 模式 符合 XXX 原 
则 ”、“XXX 模 式 违 反 了 XXX 原则 ”这 样 的 语 匈 。 


最 常见 的 7 种 面向 对 象 设 计 原 则 如 下 表 所 示 : 表 17 种 常用 的 面向 对 象 设 计 原 则 


设计 原则 名 称 定 义 使 用 频率 
单一 职责 原则 (Single Responsibility 。 一 个 类 只 负责 一 个 功能 领域 中 的 相应 职责 克 太 太太 次 
Principle, SRP) 

开 闭 原则 (Open-Closed Principle, OCP) 软件 实体 应 对 扩展 开放 ， 而 对 修改 关闭 交友 交友 克 
里 色 代 换 原 则 (Liskov Substitution 所 有 引用 基 类 对 象 的 地 方 能 够 透明 地 使 用 


Principle, LSP) 其 子 类 的 对 象 交 光 光 流 次 
依赖 倒转 原则 (Dependence Inversion 抽象 不 应 该 依赖 于 细节 ， 细 节 应 该 依赖 于 交 奖 洋 闪 半 
Principle, DIP) 抽象 
接口 隔离 原则 (Interface Segregation ”使 用 多 个 专门 的 接口 ， 而 不 使 用 单一 的 总 
Principle, ISP) 接口 a 
合成 复 用 原则 (Composite Reuse 尽量 使 用 对 象 组 合 ， 而 不 是 继承 来 达到 复 赤 赤 玉环 
Principle, CRP) 用 的 目的 

一 个 软件 实体 应 当 尽 可 能 少 地 与 其 他 衬 
迪 米 特 法 则 (Law of Demeter LoD) 人 女友 友 六 六 


发 生 相 互 作用 
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面向 对 象 设计 原则 之 单一 职责 原则 
面向 对 象 设计 原则 之 单一 职责 原则 


单一 职责 原则 是 最 简单 的 面向 对 象 设计 原则 ， 它 用 于 控制 类 的 粒度 大 小 。 单 一 职责 原则 定义 
如 下 : 单一 职责 原则 (Single Responsibility Principle, SRP) : 一 个 类 只 负责 一 个 功能 领域 中 的 相 
应 职责 ， 或 者 可 以 定义 为 : 就 一 个 类 而 言 ， 应 该 只 有 一 个 引起 它 变化 的 原因 。 


单一 职责 原则 告诉 我 们 : 一 个 类 不 能 太 “ 累 ”! 在 软件 系统 中 ， 一 个 类 (大 到 模块 ， 小 到 方法 ) 

承担 的 职责 越 多 ， 它 被 复 用 的 可 能 性 就 越 小 ， 而 且 一 个 类 承担 的 职责 过 多 ， 就 相当 于 将 这 些 

职责 耦合 在 一 起 ， 当 其 中 一 个 职责 变化 时 ， 可 能 会 影响 其 他 职责 的 运作 ， 因 此 要 将 这 些 职责 
征 行 分 离 ， 将 不 同 的 职责 封装 在 不 同 的 类 中， 即将 不 同 的 变化 原因 封装 在 不 同 的 类 中 ， 如 果 
个 职责 总 是 同时 发 生 改 变 则 可 将 它们 封装 在 同一 类 中 。 


过 
多 
单一 职责 原则 是 实现 高 内 聚 、 低 耦合 的 指导 方针 ， 它 是 最 简单 但 又 最 难 运用 的 原则 ， 需 要 设 
计 
计 


计 人 员 发 现 类 的 不 同 职责 并 将 其 分 离 ， 而 发 现 类 的 多 重 职责 需要 设计 人 员 具 有 较 强 的 分 析 设 
计 能 力 和 相关 实践 经 验 。 


下 面 通过 一 个 简单 实例 来 进一步 分 析 单 一 职责 原则 : 


Sunny 软 件 公司 开发 人 员 针 对 某 CRM (Customer Relationship Management， 客 户 关系 管理 ) 系 
统 中 客户 信息 图 形 统计 模块 提出 了 如 图 1 所 示 初 始 设计 方案 : 


图 1 初始 设计 方案 结构 图 


CustomerDataChart 


+ getConnection () : Connection 


+ findCustomers () : List 
+ createChart() :void 
+ displayChart () :void 





在 图 1 中 ，CustomerDataChart 类 中 的 方法 说 明 如 下 : getConnection() 方 法 用 于 连接 数据 库 ， 
findCustomers() 用 于 查询 所 有 的 客户 信息 ，createChart() 用 于 创建 图 表 ，displayChart() 用 于 显示 
图 表 。 

现 使 用 单一 职责 原则 对 其 进行 重 构 。 

在 图 1 中 ，CustomerDataChart 类 承担 了 太 多 的 职责 ， 既 包含 与 数据 库 相 关 的 方法 ， 又 包含 与 图 
表 生 成 和 显示 相关 的 方法 。 如 果 在 其 他 类 中 也 需要 连接 数据 库 或 者 使 用 findCustomers() 方 法 查 
询 客 户 信 息 ， 则 难以 实现 代码 的 重用 。 无 论 是 修改 数据 库 连接 方式 还 是 修改 图 表 显 示 方式 都 
需要 修改 该 类 ， 它 不 止 一 个 引起 它 变化 的 原因 ， 违 背 了 单一 职责 原则 。 因 此 需要 对 该 类 进行 
拆 分 ， 使 其 满足 单一 职责 原则 ， 类 CustomerDataChart 可 拆 分 为 如 下 三 个 类 : 

(DBUtil : 负责 连接 数据 库 ， 和 包含 数据 库 连 接 方 法 getConnection() ; 

(2) CustomerDAO : 负责 操作 数据 库 中 的 Customer 表 ， 包 含 对 Customer 表 的 增删 改 查 等 方法 ， 
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如 findCustomers() ; 
(3) CustomerDataChart : 负责 图 表 的 生成 和 显示 ， 和 包含 方 法 createChart() 和 displayChart()。 


使 用 单一 职责 原则 重 构 后 的 结构 如 图 2 所 示 : 


CustomerDataChart 
- dao : CustomerDAO 


+ createChart () : void 
+ displayChart () : void 




















CustomerDAO 
- util : DBUtiil 
+ findCustomers () : List 












DBUtil 
+ getConnection () : Connection 






图 2 重 构 后 的 结构 图 
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面向 对 钥 设 计 原 则 之 开 财 原则 
面向 对 钥 设 计 原 则 之 开 财 原则 


开 闭 原则 是 面向 对 象 的 可 复 用 设计 的 第 一 块 基石 ， 它 是 最 重要 的 面向 对 象 设计 原则 。 开 闭 原 
则 由 Bertrand Meyer 于 1988 年 提出 ， 其 定义 如 下 : 


开 闭 原则 (Open-Closed Principle, OCP) : 一 个 软件 实体 应 当 对 扩展 开放 ， 对 修改 关闭 。 即 软件 
实体 应 尽量 在 不 修改 原 有 代码 的 情况 下 进行 扩展 。 


在 开 闭 原则 的 定义 中 ， 软 件 实体 可 以 指 一 个 软件 模块 、 一 个 由 多 个 类 组 成 的 局 部 结构 或 一 个 
独立 的 类 。 


任何 软件 都 需要 面临 一 个 很 重要 的 问题 ， 即 它们 的 需求 会 随时 间 的 推移 而 发 生变 化 。 当 软件 
系统 需要 面 对 新 的 需求 时 ， 我 们 应 该 尽量 保证 系统 的 设计 框架 是 稳定 的 。 如 果 一 个 软件 设计 
符合 开 闭 原则 ， 那 么 可 以 非常 方便 地 对 系统 进行 扩展 ， 而 且 在 扩展 时 无 须 修改 现 有 代码 ， 使 
得 软件 系统 在 拥有 适应 性 和 灵活 性 的 同时 具备 较 好 的 稳定 性 和 延续 性 。 随 着 软件 规模 越 来 越 
大 ， 软 件 寿命 越 来 越 长 ， 软 件 维护 成 本 越 来 越 高 ， 设 计 满足 开 闭 原则 的 软件 系统 也 变 得 越 来 
越 重要 。 


为 了 满足 开 闭 原则 ， 需 要 对 系统 进行 抽象 化 设计 ， 抽 象 化 是 开 闭 原则 的 关键 。 在 Java、C# 等 
编程 语言 中 ， 可 以 为 系统 定义 一 个 相对 稳定 的 抽象 层 ， 而 将 不 同 的 实现 行为 移 至 具体 的 实现 
层 中 完成 。 在 很 多 面向 对 象 编程 语言 中 都 提供 了 接口 、 抽 象 类 等 机 制 ， 可 以 通过 它们 定义 系 
统 的 抽象 层 ， 再 通过 具体 类 来 进行 扩展 。 如 果 需 要 修改 系统 的 行为 ， 无 须 对 抽象 层 进行 任何 
改动 ， 只 需要 增加 新 的 具体 类 来 实现 新 的 业务 功能 即 可 ， 实 现在 不 修改 已 有 代码 的 基础 上 扩 
展 系统 的 功能 ， 达 到 开 闭 原则 的 要 求 。 


Sunny 软 件 公司 开发 的 CRM 系 统 可 以 显示 各 种 类 型 的 图 表 ， 如 饼 状 图 和 柱状 图 等 ， 为 了 支持 多 
种 图 表 显 示 方 式 ， 原 始 设计 方案 如 图 1 所 示 : 


PieChart 
+ display () : void 


ChartDisplay 


+ display (String type) : void 
] .时 
+ display () : void | 





图 1 初始 设计 方案 结构 图 
在 ChartDisplay 类 的 display() 方 法 中 存在 如 下 代码 片段 : 


If (type.equals("pie")) { 


19 


面向 对 象 设计 原则 之 开 闭 原则 


PieChart chart = new PieChart(); 
chart.display(); 


} 
else if (type.equals("bar")) { 


BarChart chart = new BarcChart(); 
chart.display(); 


在 该 代码 中 ， 如 果 需 要 增加 一 个 新 的 图 表 类 ， 如 折线 图 LineChart， 则 需要 修改 ChartDisplay 类 
的 display() 方 法 的 源 代码 ， 增 加 新 的 判断 逻辑 ， 违 反 了 开 闭 原则 。 


现 对 该 系统 进行 重 构 ， 使 之 符合 开 闭 原则 。 

在 本 实例 中 ， 由 于 在 ChartDisplay 类 的 display() 方 法 中 针对 每 一 个 图 表 类 编程 ， 因 此 增加 新 的 图 
表 类 不 得 不 修改 源 代码 。 可 以 通过 抽象 化 的 方式 对 系统 进行 重 构 ， 使 之 增加 新 的 图 表 类 时 无 
须 修改 源 代码 ， 满 足 开 闭 原则 。 

具体 做 法 如 下 : 

(1) 增加 一 个 抽象 图 表 类 AbstractChart， 将 各 种 具体 图 表 类 作为 其 子 类 ; 


(2) ChartDisplay 类 针对 抽象 图 表 类 进行 编程 ， 由 客户 端 来 决定 使 用 哪 种 具体 图 表 。 


AbstractChart 
{abstract} 


+ display () : void 
AN 


重 构 后 结构 如 图 2 所 示 : 


ChartDisplay 
- chart : AbstractChart 


+ setChart (AbstractChart chart) : void 
+ display () : void 























， 
' 
‘ 
» 
4 


~、 
chart.display(); 


+ display () : void 


+ display () : void 


图 2 重 构 后 的 结构 图 


在 图 2 中 ， 我 们 引入 了 抽象 图 表 类 AbstractChart， 且 ChartDisplay 针 对 抽象 图 表 类 进行 编程 ， 并 
通过 setChart( 方 法 由 客户 端 来 设置 实例 化 的 具体 图 表 对 象 ， 在 ChartDisplay 的 display() 方 法 中 调 
用 chart 对 象 的 display() 方 法 显示 图 表 。 如 果 需 要 增加 一 种 新 的 图 表 ， 如 折线 图 LineChart， 只 需 
要 将 LineChart 也 作为 AbstractChart 的 子 类 ， 在 客户 端 向 ChartDisplay 中 注入 一 个 LineChart 对 象 
即 可 ， 无 须 修 改 现 有 类 库 的 源 代码 。 


注意 : 因为 xml 和 properties 等 格式 的 配置 文件 是 纯 文 本 文件 ， 可 以 直接 通过 VI 编 辑 器 或 记事 本 
进行 编辑 ， 且 无 须 编译 ， 因 此 在 软件 开发 中 ， 一 般 不 把 对 配置 文件 的 修改 认为 是 对 系统 源 代 
码 的 修改 。 如 果 一 个 系统 在 扩展 时 只 涉及 到 修改 配置 文件 ， 而 原 有 的 Java 代 码 或 C# 代 码 没有 
做 任何 修改 ， 该 系统 即 可 认为 是 一 个 符合 开 闭 原则 的 系统 。 
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面向 对 象 设 计 原 则 之 里 色 代 换 原 则 


面向 对 畸 设 计 原 则 之 里 民 代 换 原 则 
面向 对 畸 设 计 原 则 之 里 民 代 换 原 则 


里 色 代 换 原 则 由 2008 年 图 灵 奖 得 主 、 美 国 第 一 位 计算 机 科学 女 博 士 Barbara Liskov 教 授 和 卡 内 

基 - 梅 隆 大 学 Jeannette Wing 教 授 于 1994 年 提出 。 其 严格 表述 如 下 : 如 果 对 每 一 个 类 型 为 S 的 对 
象 ol， 都 有 类 型 为 T 的 对 象 02， 使 得 以 T 定 义 的 所 有 程序 P 在 所 有 的 对 象 ol 代 换 02 时 ， 程 序 P 的 

行为 没有 变化 ， 那 么 类 型 S 是 类 型 TT 的 子 类 型 。 这 个 定义 比较 抛 口 且 难以 理解 ， 因 此 我 们 一 般 

使 用 它 的 另 一 个 通俗 版 定义 : 里 氏 代 换 原 则 (Liskov Substitution Principle, LSP) : 所 有 引用 基 类 
( 父 类 ) 的 地 方 必 须 能 透明 地 使 用 其 子 类 的 对 象 。 


里 氏 代 换 原 则 告诉 我 们 ， 在 软件 中 将 一 个 基 类 对 象 替换 成 它 的 子 类 对 象 ， 程 序 将 不 会 产生 任 
何 错误 和 异常 ， 反 过 来 则 不 成 立 ， 如 果 一 个 软件 实体 使 用 的 是 一 个 子 类 对 象 的 话 ， 那 么 它 不 
一 定 能 够 使 用 基 类 对 象 。 例 如 : 我 喜欢 动物 ， 那 我 一 定 喜欢 狗 ， 因 为 狗 是 动物 的 子 类 ; 但 是 
我 喜欢 狗 ， 不 能 据 此 断定 我 喜欢 动物 ， 因 为 我 并 不 喜欢 老 和 所， 虽然 它 也 是 动物 。 


例如 有 两 个 类 ， 一 个 类 为 BaseClass， 另 一 个 是 SubClass 类 ， 并 且 SubClass 类 是 BaseClass 类 的 子 
类 ， 那 么 一 个 方法 如 果 可 以 接受 一 个 BaseClass 类 型 的 基 类 对 象 base 的 话 ， 如 : method1(base)， 
那么 它 必 然 可 以 接受 一 个 BaseClass 类 型 的 子 类 对 象 Sub，method1(sub) 能 够 正常 运行 。 反 过 来 
的 代 换 不 成 立 ， 如 一 个 方法 method2 接 受 BaseClass 类 型 的 子 类 对 象 sSub 为 参数 : method2(sub)， 
那么 一 般 而 言 不 可 以 有 method2(base)， 除 非 是 重 载 方法 。 


里 氏 代 换 原则 是 实现 开 闭 原则 的 重要 方式 之 一 ， 由 于 使 用 基 类 对 象 的 地 方 都 可 以 使 用 子 类 对 
象 ， 因 此 在 程序 中 尽量 使 用 基 类 类 型 来 对 对 象 进行 定义 ， 而 在 运行 时 再 确定 其 子 类 类 型 ， 用 
子 类 对 象 来 替换 父 类 对 象 。 


在 使 用 里 氏 代 换 原 则 时 需要 注意 如 下 几 个 问题 : 


(1) 子 类 的 所 有 方法 必须 在 父 类 中 声明 ， 或 子 类 必须 实现 父 类 中 声明 的 所 有 方法 。 根 据 里 氏 代 
换 原 则 ， 为 了 保证 系统 的 扩展 性 ， 在 程序 中 通常 使 用 父 类 来 进行 定义 ， 如 果 一 个 方法 只 存在 
子 类 中 ， 在 父 类 中 不 提供 相应 的 声明 ， 则 无 法 在 以 父 类 定义 的 对 象 中 使 用 该 方法 。 


(2) 我 们 在 运用 里 氏 代 换 原则 时 ， 尽 量 把 父 类 设计 为 抽象 类 或 者 接口 ， 让 子 类 继承 父 类 或 实现 
父 接 口 ， 并 实现 在 父 类 中 声明 的 方法 ， 和 运行 时 ， 子 类 实例 替换 父 类 实例 ， 我 们 可 以 很 方便 地 
扩展 系统 的 功能 ， 同 时 无 须 修改 原 有 子 类 的 代码 ， 增 加 新 的 功能 可 以 通过 增加 一 个 新 的 子 类 
来 实现 。 里 氏 代 换 原 则 是 开 闭 原则 的 具体 实现 手段 之 一 。 


(3) Java 语 言 中 ， 在 编译 阶段 ，Java 编 译 器 会 检查 一 个 程序 是 否 符合 里 氏 代 换 原 则 ， 这 是 一 个 
与 实现 无 关 的 、 纯 语法 意义 上 的 检查 ， 但 Java 编 译 器 的 检查 是 有 局 限 的 。 

在 Sunny 软 件 公司 开发 的 CRM 系 统 中 ， 客 户 (Customen 可 以 分 为 VIP 客户 (VIPCustomem 和 普通 
客户 (CommonCustomen 两 类 ， 系 统 需要 提供 一 个 发 送 Email 的 功能 ， 原 始 设计 方案 如 图 1 所 
示 : 


图 1 原始 结构 图 
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- name : String 
- email : String 


+ getName () : String 
i + SetName (String name) : void 
| + getEmail () : String 
| + setEmail (String email) :void 
EmailSender 










+ Send (CommonCustomer customer) : void 
+ Send (MPCustomer customer) : void 


VIPCustomer 
- name : String 
- email : String 


+ getName () : String 
+ SetName (String name) : void 
+ getEmail () : String 
+ setEmail (String email) :void 


在 对 系统 进行 进一步 分 析 后 发 现 ， 无 论 是 普通 客户 还 是 VIP 客户 ， 发 送 邮 件 的 过 程 都 是 相同 
的 ， 也 就 是 说 两 个 send() 方 法 中 的 代码 重复 ， 而 且 在 本 系统 中 还 将 增加 新 类 型 的 客户 。 为 了 让 
系统 具有 更 好 的 扩展 性 ， 同 时 减少 代码 重复 ， 使 用 里 氏 代 换 原则 对 其 进行 重 构 。 


在 本 实例 中 ， 可 以 考虑 增加 一 个 新 的 抽象 客户 类 Customer， 而 将 CommonCustomer 和 
VIPCustomer 类 作为 其 子 类 ， 邮 件 发 送 类 EmailSender 类 针对 抽象 客户 类 Customer 编 程 ， 根 据 里 
色 代 换 原 则 ， 能 够 接受 基 类 对 象 的 地 方 必 然 能 够 接受 子 类 对 象 ， 因 此 将 EmailSender 中 的 send0) 
方法 的 参数 类 型 改 为 Customer， 如 果 需 要 增加 新 类 型 的 客户 ， 只 需 将 其 作为 Customer 类 的 子 类 
即 可 。 重 构 后 的 结构 如 图 2 所 示 : 
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EmailSender 


+ send (Customer customer) : void 






Customer 


# name : String 

# email : String 

+ getName () : String 

+ setName (String name) : void 

+ getEmail () : String 

+ setEmail (String email) : void 
A 












图 2 重 构 后 的 结构 图 


里 氏 代 换 原则 是 实现 开 闭 原则 的 重要 方式 之 一 。 在 本 实例 中 ， 在 传递 参数 时 使 用 基 类 对 象 ， 
除 此 以 外 ， 在 定义 成 员 变 量 、 定 义 局 部 变量 、 确 定 方法 返回 类 型 时 都 可 使 用 里 氏 代 换 原 则 。 
针对 基 类 编程 ， 在 程序 运行 时 再 确定 具体 子 类 。 


扩展 
里 反 代 换 原 则 以 Barbara Liskov (区 芭 拉 : 利 斯 科 夫 ) 教授 的 姓氏 命名 。 芭 区 拉 : 利 斯 科 夫 : 美国 
计算 机 科学 家 ，2008 年 图 灵 奖 得 主 ，2004 年 约翰 : 冯 诺 依 曼 奖 得 主 ， 美 国 工程 院 院士 ， 美国 艺 


术 与 科学 院 院士 ， 美 国 计 算 机 协会 会 士 ， 麻 省 理工 学 院 电 子 电气 与 计算 机 科学 系 教授 ， 美 国 
第 一 位 计算 机 科学 女 博士 。 
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面向 对 象 设 计 原 则 之 依赖 倒转 原则 


面向 对 参 设 计 原 则 之 依赖 倒转 原则 
面向 对 胃 设 计 原 则 之 依赖 倒转 原则 


如 果 说 开 闭 原则 是 面向 对 象 设计 的 目标 的 话 ， 那 么 依赖 倒转 原则 就 是 面向 对 象 设计 的 主要 实 
现 机 制 之 一 ， 它 是 系统 抽象 化 的 具体 实现 。 依 赖 倒转 原则 是 Robert C. Martin 在 1996 年 

为 “C++Reporter” 所 写 的 专栏 Engineering Notebook 的 第 三 篇 ， 后 来 加 入 到 他 在 2002 年 出 版 的 经 
典 著作 “Agile Software Development, Principles, Patterns, and Practices” 一 书 中 。 依 赖 倒转 原则 定 
义 如 下 : 依赖 倒转 原则 (Dependency Inversion Principle, DIP) : 抽象 不 应 该 依赖 于 细节 ， 细 节 应 
当 依 赖 于 抽象 。 换 言 之 ， 要 针对 接口 编程 ， 而 不 是 针对 实现 编程 。 


依赖 倒转 原则 要 求 我 们 在 程序 代码 中 传递 参数 时 或 在 关联 关系 中 ， 尽 量 引 用 层次 高 的 抽象 层 
类 ， 即 使 用 接口 和 抽象 类 进行 变量 类 型 声明 、 参 数 类 型 声明 、 方 法 返回 类 型 声明 ， 以 及 数据 
类 型 的 转换 等 ， 而 不 要 用 具体 类 来 做 这 些 事情 。 为 了 确保 该 原则 的 应 用 ， 一 个 具体 类 应 当 只 
实现 接口 或 抽象 类 中 声明 过 的 方法 ， 而 不 要 给 出 多 余 的 方法 ， 否 则 将 无 法 调用 到 在 子 类 中 增 
加 的 新 方法 。 


在 引入 抽象 层 后 ， 系 统 将 具有 很 好 的 灵活 性 ， 在 程序 中 尽量 使 用 抽象 层 进行 编程 ， 而 将 具体 
类 写 在 配置 文件 中 ， 这 样 一 来 ， 如 果 系 统 行为 发 生变 化 ， 只 需要 对 抽象 层 进行 扩展 ， 并 修改 
配置 文件 ， 而 无 须 修改 原 有 系统 的 源 代码 ， 在 不 修改 的 情况 下 来 扩展 系统 的 功能 ， 满 足 开 财 
原则 的 要 求 。 


在 实现 依赖 倒转 原则 时 ， 我 们 需要 针对 抽象 层 编程 ， 而 将 具体 类 的 对 象 通过 依赖 注入 
(DependencyInjection, DD) 的 方式 注入 到 其 他 对 象 中 ， 依 赖 注入 是 指 当 一 个 对 象 要 与 其 他 对 象 发 
生 依赖 关系 时 ， 通 过 抽象 来 注入 所 依赖 的 对 象 。 常 用 的 注入 方式 有 三 种 ， 分 别 是 : 构造 注 

入 ， 设 值 注入 (Setter 注 入 ) 和 接口 注入 。 构 造 注 入 是 指 通过 构造 函数 来 传 入 具体 类 的 对 象 ， 
设 值 注入 是 指 通 过 Setter 方 法 来 传 入 具体 类 的 对 象 ， 而 接口 注入 是 指 通 过 在 接口 中 声明 的 业务 
方法 来 传 入 具体 类 的 对 象 。 这 些 方法 在 定义 时 使 用 的 是 抽象 类 型 ， 在 运行 时 再 传 入 具体 类 型 
的 对 象 ， 由 子 类 对 象 来 覆盖 父 类 对 象 。 


扩展 
软件 工程 大 师 Martin Fowler 在 其 文章 Inversion of Control Containers and the Dependency Injection 


pattern 中 对 依赖 注入 进行 了 深入 的 分 析 ， 参 考 链接 : 
http://martinfowler.com/articles/injection.html 

下 面 通 过 一 个 简单 实例 来 加 深 对 依赖 倒转 原则 的 理解 : 

Sunny 软 件 公司 开发 人 员 在 开发 茶 CRM 系 统 时 发 现 : 该 系统 经 常 需要 将 存储 在 TXT 或 Excel 文 


件 中 的 客户 信息 转 存 到 数据 库 中 ， 因 此 需要 进行 数据 格式 转换 。 在 客户 数据 操作 类 中 将 调用 
数据 格式 转换 类 的 方法 实现 格式 转换 和 数据 库 插入 操作 ， 初 始 设计 方案 结构 如 图 1 所 示 : 
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TXTDataConvertor 


+ readFile () : void 


CustomerDAO 


+ addCustomers () : void 


ExcelDataConvertor 


+ readFile () : void 





图 1 初始 设计 方案 结构 图 


在 编码 实现 图 1 所 示 结 构 时 ，Sunny 软 件 公司 开发 人 员 发 现 该 设计 方案 存在 一 个 非常 严重 的 问 
题 ， 由 于 每 次 转换 数据 时 数据 来 源 不 一 定 相同 ， 因 此 需要 更 换 数据 转换 类 ， 如 有 时 候 需 要 将 
TXTDataConvertor 改 为 ExcelDataConvertor， 此 时 ， 需 要 修改 CustomerDAO 的 源 代码 ， 而 且 在 
引入 并 使 用 新 的 数据 转换 类 时 也 不 得 不 修改 CustomerDAO 的 源 代码 ， 系 统 扩展 性 较 差 ， 违 反 
了 开 闭 原则 ， 现 需要 对 该 方案 进行 重 构 。 


在 本 实例 中 ， 由 于 CustomerDAO 针 对 具体 数据 转换 类 编程 ， 因 此 在 增加 新 的 数据 转换 类 或 者 
更 换 数 据 转 换 类 时 都 不 得 不 修改 CustomerDAO 的 源 代码 。 我 们 可 以 通过 引入 抽象 数据 转换 类 
解决 该 问题 ， 在 引入 抽象 数据 转换 类 DataConvertor 之 后 ，CustomerDAO 针 对 抽象 类 
DataConvertor 编 程 ， 而 将 具体 数据 转换 类 名 存储 在 配置 文件 中 ， 符 合 依赖 倒转 原则 。 根 据 里 
色 代 换 原 则 ， 程 序 运 行 时 ， 有 具体 数据 转换 类 对 象 将 替换 DataConvertor 类 型 的 对 象 ， 程 序 不 会 
出 现任 何 问 题 。 更 换 具 体 数据 转换 类 时 无 须 修改 源 代 码 ， 只 需要 修改 配置 文件 ; 如 果 需 要 增 
加 新 的 具体 数据 转换 类 ， 只 要 将 新 增 数 据 转 换 类 作为 DataConvertor 的 子 类 并 修改 配置 文件 即 
可 ， 原 有 代码 无 须 做 任何 修改 ， 满 足 开 闭 原则 。 重 构 后 的 结构 如 图 2 所 示 : 









TXTDataConvertor 


+ readFile () : void 














DataConvertor i 


{abstract} 



















+ addCustomers () : void 












ExcelDataConvertor + readFile () : void 


+ readFile () : void 








图 2 重 构 后 的 结构 图 


在 上 述 重 构 过 程 中 ， 我 们 使 用 了 开 闭 原则 、 里 氏 代 换 原则 和 依赖 倒转 原则 ， 在 大 多 数 情况 
下 ， 这 三 个 设计 原则 会 同时 出 现 ， 开 闭 原则 是 目标 ， 里 氏 代 换 原则 是 基础 ， 依 赖 倒转 原则 是 
手段 ， 它 们 相辅相成 ， 相 互补 充 ， 目 标 一 致 ， 只 是 分 析 问 题 时 所 站 角度 不 同 而 已 。 

扩展 
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Robert C. Martin(Bob 大 叔 ) : Object Mentor 公 司 总 裁 ， 面 向 对 象 设 计 、 模 式 、UML、 敏 捷 方 法 
学 和 极限 编程 领域 内 的 资深 顾问 。 


敏捷 软件 开发 
原则 、 模 式 与 实践 
pe 





再 上 两 张 Bob 大 叔 的 “玉照 ”， 大 笑 : 
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面向 对 参 设 计 原 则 之 接口 隔离 原则 
面向 对 胃 设 计 原 则 之 接口 隔离 原则 


接口 隔离 原则 定义 如 下 : 


接口 隔离 原则 (Interface Segregation Principle, ISP) : 使 用 多 个 专门 的 接口 ， 而 不 使 用 单一 
的 总 接口 ， 即 客户 端 不 应 该 依赖 那些 它 不 需要 的 接口 。 


根据 接口 隔离 原则 ， 当 一 个 接口 太 大 时 ， 我 们 需要 将 它 分 割 成 一 些 更 细小 的 接口 ， 使 用 该 接 
口 的 客户 端 仅 需 知道 与 之 相关 的 方法 即 可 。 每 一 个 接口 应 该 承担 一 种 相对 独立 的 角色 ， 不 干 
不 该 干 的 事 ， 该 干 的 事 都 要 干 。 这 里 的 “接口 ”往往 有 两 种 不 同 的 含义 : 一 种 是 指 一 个 类 型 所 有 具 
有 的 方法 特征 的 集合 ， 仅 仅 是 一 种 逻辑 上 的 抽象 ; 另外 一 种 是 指 某 种 语言 具体 的 “接口 "定义 ， 
有 严格 的 定义 和 结构 ， 比 如 Java 语 言 中 的 interface。 对 于 这 两 种 不 同 的 含义 ，ISP 的 表达 方式 以 
及 含义 都 有 所 不 同 : 


(1) 当 把 “接口 "理解 成 一 个 类 型 所 提供 的 所 有 方法 特征 的 集合 的 时 候 ， 这 就 是 一 种 逻辑 上 的 概 
念 ， 接 口 的 划分 将 直接 带 来 类 型 的 划分 。 可 以 把 接口 理解 成 角色 ， 一 个 接口 只 能 代表 一 个 角 
色 ， 每 个 角色 都 有 它 特定 的 一 个 接口 ， 此 时 ， 这 个 原则 可 以 叫做 “角色 隔离 原则 ”。 


(2) 如 果 把 “接口 "理解 成 狭义 的 特定 语言 的 接口 ， 那 么 ISP 表 达 的 意思 是 指 接口 仅仅 提供 客户 端 
需要 的 行为 ， 客 户 端 不 需要 的 行为 则 隐藏 起 来 ， 应 当 为 客户 端 提 供 尽 可 能 小 的 单独 的 接口 ， 

而 不 要 提供 大 的 总 接口 。 在 面向 对 象 编程 语言 中 ， 实 现 一 个 接口 就 需要 实现 该 接口 中 定义 的 

所 有 方法 ， 因 此 大 的 总 接口 使 用 起 来 不 一 定 很 方便 ， 为 了 使 接口 的 职责 单一 ， 需 要 将 大 接口 

中 的 方法 根据 其 职责 不 同 分 别 放 在 不 同 的 小 接口 中 ， 以 确保 每 个 接口 使 用 起 来 都 较为 方便 ， 

并 都 承担 某 一 单一 角色 。 接 口 应 该 尽量 细 化 ， 同 时 接口 中 的 方法 应 该 尽量 少 ， 每 个 接口 中 只 

包含 一 个 客户 端 (如 子 模块 或 业务 逻辑 类 ) 所 需 的 方法 即 可 ， 这 种 机 制 也 称 为 “定制 服务 ?”， 即 
为 不 同 的 客户 端 提 供 宽窄 不 同 的 接口 。 


下 面 通过 一 个 简单 实例 来 加 深 对 接口 隔离 原则 的 理解 : 
Sunny 软 件 公司 开发 人 员 针 对 某 CRM 系 统 的 客户 数据 显示 模块 设计 了 如 图 1 所 示 接 口 ， 其 中 方 
法 dataRead(O 用 于 从 文件 中 读 取 数 据 ， 方 法 transformToXML(O 用 于 将 数据 转换 成 XML 格式 ， 方 


法 createChart() 用 于 创建 图 表 ， 方 法 displayChart() 用 于 显示 图 表 ， 方 法 createReport() 用 于 创建 文 
字 报 表 ， 方 法 displayReportO 用 于 显示 文字 报表 。 


”CustomerDataDisplay ConcreteClass 


.= 
+ dataRead () 
EE 


+ transformToXML () 
EE + createChart () 
i + displayChart () 
+ createReport () 
+ displayReport () 





图 1 初始 设计 方案 结构 图 


在 实际 使 用 过 程 中 发 现 该 接口 很 不 灵活 ， 例 如 如 果 一 个 具体 的 数据 显示 类 无 须 进 行 数 据 转 换 
( 源 文 件 本 身 就 是 XML 格式 ) ， 但 由 于 实现 了 该 接口 ， 将 不 得 不 实现 其 中 声明 的 
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transformToXMIL() 方 法 (至少 需要 提供 一 个 空 实现 ) ; 如 果 需 要 创建 和 显示 图 表 ， 除 了 需 实现 
与 图 表 相 关 的 方法 外 ， 还 需要 实现 创建 和 显示 文字 报表 的 方法 ， 否 则 程序 编译 时 将 报错 。 
现 使 用 接口 隔离 原则 对 其 进行 重 构 。 

在 图 1 中 ， 由 于 在 接口 CustomerDataDisplay 中 定义 了 大 多 方法 ， 即 该 接口 承担 了 大 多 职责 ， 一 
方面 导致 该 接口 的 实现 类 很 庞大 ， 在 不 同 的 实现 类 中 都 不 得 不 实现 接口 中 定义 的 所 有 方法 ， 
灵活 性 较 差 ， 如 果 出 现 大 量 的 空 方法 ， 将 导致 系统 中 产生 大 量 的 无 用 代码 ， 影 响 代 码 质 量 ; 
另 一 方面 由 于 客户 端 针对 大 接口 编程 ， 将 在 一 定 程序 上 破坏 程序 的 封装 性 ， 客 户 端 看 到 了 不 
应 该 看 到 的 方法 ， 没 有 为 客户 端 定制 接口 。 因 此 需要 将 该 接口 按照 接口 隔离 原则 和 单一 职责 
原则 进行 重 构 ， 将 其 中 的 一 些 方法 封装 在 不 同 的 小 接口 中 ， 确 保 每 一 个 接口 使 用 起 来 都 较为 
方便 ， 并 都 承担 菜 一 单一 角色 ， 每 个 接口 中 只 包含 一 个 客户 端 (如 模块 或 类 ) 所 需 的 方法 即 
可 。 


通过 使 用 接口 隔离 原则 ， 本 实例 重 构 后 的 结构 如 图 2 所 示 : 


”DataHandler 


+ dataRead () 


” XMLTransformer 
+ transform ToXML () 









ConcreteClass 





+ dataRead () 
+ createChart () 
+ displayChart () 





~“ ChartHandler 


+ createChart() | 
+ displayChart () 


” ReportHandler 


+ createReport () 
+ displayReport () 





图 2 重 构 后 的 结构 图 


在 使 用 接口 隔离 原则 时 ， 我 们 需要 注意 控制 接口 的 粒度 ， 接 口 不 能 太 小 ， 如 果 太 小 会 导致 系 
统 中 接口 泛滥， 不 利于 维护 ; 接口 也 不 能 太 大 ， 太 大 的 接口 将 违背 接口 隔离 原则 ， 灵 活性 较 
差 ， 使 用 起 来 很 不 方便 。 一 般 而 言 ， 接 口中 仅 包 含 为 菜 一 类 用 户 定制 的 方法 即 可 ， 不 应 该 强 
迫 客 户 依赖 于 那些 它们 不 用 的 方法 。 


扩展 
在 《敏捷 软件 开发 原则 、 模 式 与 实践 》 一 书 中 ，RobertC. Martin 从 解决 “接口 污染 ”的 角度 


对 接口 隔离 原则 进行 了 详细 的 介绍 ， 大 家 可 以 参阅 该 书 第 12 章 一 一 接口 隔离 原则 (ISP) 进 行 深 
入 的 学 习 。 
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面向 对 参 设 计 原 则 之 合成 复 用 原则 
面向 对 胃 设 计 原 则 之 合成 复 用 原则 


合成 复 用 原则 又 称 为 组 合 /聚合 复 用 原则 (Composition/Aggregate Reuse Principle, CARP)， 其 定 
义 如 下 : 


合成 复 用 原则 (Composite Reuse Principle, CRP) : 尽量 使 用 对 象 组 合 ， 而 不 是 继承 来 达到 复 
用 的 目的 。 


合成 复 用 原则 就 是 在 一 个 新 的 对 象 里 通过 关联 关系 ( 包括 组 合 关系 和 聚合 关系 ) 来 使 用 一 些 
已 有 的 对 象 ， 使 之 成 为 新 对 象 的 一 部 分 ; 新 对 象 通过 委派 调用 已 有 对 象 的 方法 达到 复 用 功能 
的 目的 。 简 言 之 : 复 用 时 要 尽量 使 用 组 合 /聚合 关系 〈 关 联 关系 ) ， 少 用 继承 。 


在 面向 对 象 设计 中 ， 可 以 通过 两 种 方法 在 不 同 的 环境 中 复 用 已 有 的 设计 和 实现 ， 即 通过 组 合 / 
聚合 关系 或 通过 继承 ， 但 首先 应 该 考虑 使 用 组 合 / 聚 合 ， 组 合 /聚合 可 以 使 系统 更 加 灵活 ， 降 低 
类 与 类 之 间 的 耦合 度 ， 一 个 类 的 变化 对 其 他 类 造成 的 影响 相对 较 少 ; 其 次 才 考虑 继承 ， 在 使 

用 继承 时 ， 需 要 严格 遵循 里 氏 代 换 原 则 ， 有 效 使 用 继承 会 有 助 于 对 问题 的 理解 ， 降 低 复 杂 

度 ， 而 滥用 继承 反而 会 增加 系统 构建 和 维护 的 难度 以 及 系统 的 复杂 度 ， 因 此 需要 惯 重 使 用 继 

承 复 用 。 


通过 继承 来 进行 复 用 的 主要 问题 在 于 继承 复 用 会 破坏 系统 的 封装 性 ， 因 为 继承 会 将 基 类 的 实 
现 细节 暴露 给 予 关 ， 由 于 基 类 的 内 部 细节 通常 对 子 类 来 说 是 可 见 的 ， 所 以 这 种 复 用 又 称 < 白 

箱 " 复 用 ， 如 果 基 类 发 生 改 变 ， 那 么 子 类 的 实现 也 不 得 不 发 生 改 变 ; 从 基 类 继承 而 来 的 实现 是 
静态 的 ， 不 可 能 在 运行 时 发 生疏 变 ， 没 有 足够 的 灵活 性 ; 而 且 继承 只 能 在 有 限 的 环境 中 使 用 
(如 类 没有 声明 为 不 能 被 继承 ) 。 


扩展 


对 于 继承 的 深入 理解 ， 大 家 可 以 参考 《软件 架构 设计 》 一 书 作者 温 显 先生 的 文章 一 一 《 见 山 
只 是 山 见 水 只 是 水 一 一 提升 对 继承 的 认识 》。 


由 于 组 合 或 聚合 关系 可 以 将 已 有 的 对 象 (也 可 称 为 成 员 对 象 ) 纳入 到 新 对 象 中 ， 使 之 成 为 新 
对 象 的 一 部 分 ， 因 此 新 对 象 可 以 调用 已 有 对 象 的 功能 ， 这 样 做 可 以 使 得 成 员 对 象 的 内 部 实现 
细节 对 于 新 对 象 不 可 见 ， 所 以 这 种 复 用 又 称 为 “黑箱 ” 复 用 ， 相 对 继承 关系 而 言 ， 其 耦合 度 相 对 
较 低 ， 成 员 对 象 的 变化 对 新 对 象 的 影响 不 大 ， 可 以 在 新 对 象 中 根据 实际 需要 有 选择 性 地 调用 
成 员 对 象 的 操作 ; 合成 复 用 可 以 在 运行 时 动态 进行 ， 新 对 象 可 以 动态 地 引用 与 成 员 对 象 类 型 
相同 的 其 他 对 象 。 





一 般 而 言 ， 如 果 两 个 类 之 间 是 “Has-A” 的 关系 应 使 用 组 合 或 聚合 ， 如 果 是 “Js-A” 关 系 可 使 用 继 
承 。"Is-A" 是 严格 的 分 类 学 意义 上 的 定义 ， 意 思 是 一 个 类 是 另 一 个 类 的 "一 种 " ; 而 "Has-A" 则 不 
同 ， 它 表示 茶 一 个 角色 具有 茶 一 项 责任 。 


下 面 通 过 一 个 简单 实例 来 加 深 对 合成 复 用 原则 的 理解 : 
Sunny 软 件 公司 开发 人 员 在 初期 的 CRM 系 统 设计 中 ， 考 虑 到 客户 数量 不 多 ， 系 统 采用 MySQL 
作为 数据 库 ， 与 数据 库 操作 有 关 的 类 如 CustomerDAO 类 等 都 需要 连接 数据 库 ， 连 接 数据 库 的 


方法 getConnection() 封 装 在 DBUtil 类 中 ， 由 于 需要 重用 DBUtil 类 的 getConnection() 方 法 ， 设 计 人 
员 将 CustomerDAO 作 为 DBUtil 类 的 子 类 ， 初 始 设计 方案 结构 如 图 1 所 示 : 
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图 1 初始 设计 方案 结构 图 

随 着 客户 数量 的 增加 ， 系 统 决 定 升级 为 Oracle 数 据 库 ， 因 此 需要 增加 一 个 新 的 OracleDBUtil 类 
来 连接 Oracle 数 据 库 ， 由 于 在 初始 设计 方案 中 CustomerDAO 和 DBUtil 之 间 是 继承 关系 ， 因 此 在 
更 换 数 据 库 连接 方式 时 需要 修改 CustomerDAO 类 的 源 代 码 ， 将 CustomerDAO 作 为 OracleDBUtil 
的 子 类 ， 这 将 违反 开 闭 原则 。【 当 然 也 可 以 修改 DBUtil 类 的 源 代 码 ， 同 样 会 违反 开 闭 原 

则 。]】 


现 使 用 合成 复 用 原则 对 其 进行 重 构 。 


根据 合成 复 用 原则 ， 我 们 在 实现 复 用 时 应 该 多 用 关联 ， 少 用 继承 。 因 此 在 本 实例 中 我 们 可 以 
使 用 关联 复 用 来 取代 继承 复 用 ， 重 构 后 的 结构 如 图 2 所 示 : 





图 2 重 构 后 的 结构 图 


在 图 2 中 ，CustomerDAO 和 DBUtil 之 间 的 关系 由 继承 关系 变 为 关联 关系 ， 采 用 依赖 注入 的 方式 
将 DBUtil 对 象 注 入 到 CustomerDAO 中 ， 可 以 使 用 构造 注入 ， 也 可 以 使 用 Setter 注 入 。 如 果 需 要 
对 DBUtil 的 功能 进行 扩展 ， 可 以 通过 其 子 类 来 实现 ， 如 通过 子 类 OracleDBUtil 来 连接 Oracle 数 
据 库 。 由 于 CustomerDAO 针 对 DBUtil 编 程 ， 根 据 里 色 代 换 原 则 ，DBUtil 子 类 的 对 象 可 以 覆盖 
DBUtil 对 和 象 ， 只 需 在 CustomerDAO 中 注入 子 类 对 象 即 可 使 用 子 类 所 扩展 的 方法 。 例 如 在 
CustomerDAO 中 注入 OracleaDBUtil 对 象 ， 即 可 实现 Oracle 数 据 库 连接 ， 原 有 代码 无 须 进 行 修 
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改 ， 而 且 还 可 以 很 灵活 地 增加 新 的 数据 库 连 接 方式 。 
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面向 对 象 设 计 原 则 之 迪 米 特 法 则 
面向 对 象 设 计 原 则 之 迪 米 特 法 则 


迪 米 特 法 则 来 自 于 1987 年 美国 东北 大 学 (Northeastern University) 一 个 名 为 “Demeter” 的 研究 项 
目 。 迪 米 特 法 则 又 称 为 最 少 知识 原则 (LeastKnowledge Principle, LKP)， 其 定义 如 下 : 


迪 米 特 法 则 (Law of Demeter, LoD) : 一 个 软件 实体 应 当 尽 可 能 少 地 与 其 他 实体 发 生 相 互 作 
用 。 


i i ， 那么 当 其 中 茶 一 个 模块 发 生 修改 时 ， 就 会 尽量 少 地 影响 其 他 
模块 ， 扩 展会 相对 容易 ， 这 是 对 软件 实体 之 间 通 信 的 限制 ， 迪 米 特 法 则 要 求 限制 软件 实体 之 
间 通 信 的 宽 度 和 深度 。 。 迪 米 特 法 则 可 降低 系统 的 耦合 度 ， 使 类 与 类 之 间 保 持 松散 的 耦合 关 
系 o 


迪 米 特 法 则 还 有 几 种 定义 形式 ， 包 括 : 不 要 和 “陌生 人 ”说 话 、 只 与 你 的 直接 朋友 通信 等 ， 在 迪 
米 特 法 则 中 ， 对 于 一 个 对 象 ， 其 朋友 包括 以 下 几 类 : 


(1) 当前 对 象 本 身 (this) ; 

(2) 以 参数 形式 传 入 到 当前 对 象 方法 中 的 对 象 ; 

(3) 当前 对 象 的 成 员 对 象 ; 

(4) 如 果 当 前 对 象 的 成 员 对 象 是 一 个 集合 ， 那 么 集合 中 的 元 素 也 都 是 朋友 ; 
(5) 当前 对 象 所 创建 的 对 象 。 


任何 一 个 对 象 ， 如 果 满 足 上 面 的 条 件 之 一 ， 就 是 当前 对 象 的 “朋友 ”， 否 则 就 是 “陌生 人 ”。 在 应 
用 迪 米 特 法 则 时 ， 一 个 对 象 只 能 与 。 不 要 与 “陌生 人 ”发 生 直 接 交 互 ， 这 样 做 
可 以 降低 系统 的 耦合 度 ， 一 个 对 象 的 改变 不 会 给 太 多 其 他 对 象 带 来 影响 。 


迪 米 特 法 则 要 求 我 们 在 设计 系统 时 ， 应 该 尽量 减少 对 象 之 间 的 交互 ， 如 果 两 个 对 象 之 间 不 必 
彼此 直接 通信 ， 那 么 这 两 个 对 象 就 不 应 当 发 生 任何 直接 的 相互 作用 ， 如 果 其 中 的 一 个 对 象 需 
要 调用 另 一 个 对 象 的 某 一 个 方法 的 话 ， 可 以 通过 第 三 者 转发 这 个 调用 。 简 言 之 ， 就 是 通过 引 
入 一 个 合理 的 第 三 者 来 降低 现 有 对 象 之 间 的 耦合 度 。 


在 将 迪 米 特 法 则 运用 到 系统 设计 中 时 ， 要 注意 下 面 的 几 点 : 在 类 的 划分 上 ， 应 当 尽 量 创建 松 
耦合 的 类 ， 类 之 间 的 耦合 度 越 低 ， 就 越 有 利于 复 用 ， 一 个 处 在 松 耦 合 中 的 类 一 旦 被 修改 ， 不 
会 对 关联 的 类 造成 太 大 波及 ; 在 类 的 结构 设计 上 ， 每 一 个 类 都 应 当 尽 量 降低 其 成 员 变 量 和 成 
员 也 数 的 访问 权限 ; 在 类 的 设计 上 ， 只 要 有 可 能 ， 一 个 类 型 应 当 设计 成 不 变 类 ; 在 对 其 他 类 
的 引用 上 ， 一 个 对 象 对 其 他 对 象 的 引用 应 当 降 到 最 低 。 


下 面 通过 一 个 简单 实例 来 加 深 对 迪 米 特 法 则 的 理解 : 


Sunny 软 件 公司 所 开发 CRM 系 统 包 含 很 多 业务 操作 窗口 ， 在 这 些 窗口 中 ， 茶 些 界 面 控件 之 间 存 
在 复杂 的 交互 关系 ， 一 个 控件 事件 的 触发 将 导致 多 个 其 他 界面 控件 产生 响应 ， 例 如 ， 当 一 个 
按钮 (Button) 被 单 击 时 ， 对 应 的 列表 框 (List)、 组 合 框 (ComboBox)、 文 本 框 (TextBox)、 文 本 标 
签 (Label) 等 都 将 发 生 改 变 ， 在 初始 设计 方案 中 ， 界 面 控件 之 间 的 交互 关系 可 简化 为 如 图 1 所 示 
结构 : 
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EE 
-总 
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图 1 初始 设计 方案 结构 图 


在 图 1 中 ， 由 于 界面 控件 之 间 的 交互 关系 复杂 ， 导 致 在 该 窗口 中 增加 新 的 界面 控件 时 需要 修改 
与 之 交互 的 其 他 控件 的 源 代码 ， 系 统 扩 展 性 较 差 ， 也 不 便于 增加 和 删除 新 控件 。 


现 使 用 迪 米 特 对 其 进行 重 构 。 


在 本 实例 中 ， 可 以 通过 引入 一 个 专门 用 于 控制 界面 控件 交互 的 中 间 类 (Mediator) 来 降低 界面 控 
件 之 间 的 耦合 度 。 引 入 中 间 类 之 后 ， 界 面 控件 之 间 不 再 发 生 直 接 引 用 ， 而 是 将 请 求 先 转发 给 
中 间 类 ， 再 由 中 间 类 来 完成 对 其 他 控件 的 调用 。 当 需要 增加 或 删除 新 的 控件 时 ， 只 需 修 改 中 
间 类 即 可 ， 无 须 修改 新 增 控 件 或 已 有 控件 的 源 代 码 ， 重 构 后 结构 如 图 2 所 示 : 






| 
| 
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图 2 重 构 后 的 结构 图 
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个 创建 型 模式 
个 创建 型 模式 


e。 六 个 创建 型 模式 
o 简单 工厂 模式 - -Simple Factory Pattern 





o 王 矿 方 法 模式 -Factor Method Pattern 
sm 工厂 三 兄弟 之 工厂 方法 模式 


四 工厂 三 兄弟 之 工厂 方法 模式 (三 
四 工厂 三 兄弟 之 工厂 方法 模式 (四 ) 
o 抽象 工厂 模式 -Abstract Factory Pattern 
a 工厂 三 兄弟 之 抽象 工厂 模式 (一 ) 
四 工厂 三 兄弟 之 抽 旬 工厂 模式 〈 二 ) 
@ 工厂 三 兄弟 之 抽象 工厂 模式 (三) 
m 工厂 三 兄弟 之 抽象 工厂 模式 (四 ) 
四 工厂 三 兄弟 之 抽象 工厂 模式 〈 五 ) 
o 单 例 模式 -Singleton Pattern 














o 建造 者 模式 -Builder Pattern 
@ 复杂 对 象 的 组 装 与 创建 一 建造 者 模式 (一 ) 
@ 复杂 对 象 的 组 装 与 创建 -建造 者 模式 
mm 复杂 对 象 的 组 装 与 创建 -建造 者 模式 





bh 





简单 工厂 模式 -Simple Factory Pattern 


简单 工厂 模式 -Simple Factory Pattern 


简单 工厂 模式 -Simple Factory Pattern 


简单 工厂 模式 -Simple Factory Pattern 【学 习 难 度 : 次 友 六 次 交 ， 使 用 频 认 : 真 丰 友 六 六 ]】 





源码 下 载 


39 


工厂 三 兄弟 之 简单 工厂 模式 (一 ) 
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工厂 模式 是 最 常用 的 一 类 创建 型 设计 模式 ， 通 常 我 们 所 说 的 工厂 模式 是 指 工厂 方法 模式 ， 它 

也 是 使 用 频率 最 高 的 工厂 模式 。 本 章 将 要 学 习 的 简单 工厂 模式 是 工厂 方法 模式 的 “小 弟 ”， 它 不 
属于 GoF 23 种 设计 模式 ， 但 在 软件 开发 中 应 用 也 较为 频繁 ， 通 常 将 它 作为 学 习 其 他 工厂 模式 

的 入 门 。 此 外 ， 工 厂 方法 模式 还 有 一 位 “大 哥 ” 一 一 抽象 工厂 模式 。 这 三 种 工厂 模式 各 具 特 色 ， 
难度 也 逐个 加 大 ， 在 软件 开发 中 它们 都 得 到 了 广泛 的 应 用 ， 成 为 面向 对 象 软件 中 常用 的 创建 

对 象 的 工具 。 





1 图表 库 的 设计 


Sunny 软 件 公司 欲 基 于 Java 语 言 开发 一 套图 表 库 ， 该 图 表 库 可 以 为 应 用 系统 提供 各 种 不 同 外 观 
的 图 表 ， 例 如 柱状 图 、 饼 状 图 、 折 线 图 等 。Sunny 软 件 公司 图 表 库 设计 人 员 硕 望 为 应 用 系统 开 
发 人 员 提 供 一 套 灵 活 易 用 的 图 表 库 ， 而 且 可 以 较为 方便 地 对 图 表 库 进行 扩展 ， 以 便 能 够 在 将 
来 增加 一 些 新 类 型 的 图 表 。 


Sunny 软 件 公司 图 表 库 设计 人 员 提 出 了 一 个 初始 设计 方案 ， 将 所 有 图 表 的 实现 代码 封装 在 一 个 
Chart 类 中 ， 其 框架 代码 如 下 所 示 : 


class Chart { 
private String type; // 图 表 类 型 


public Chart(Object[][] data, String type) { 
this.type = type; 

if (type.equalsIgnoreCase("histogram")) { 
// 初 始 化 柱状 图 


else if (type.equalsIignoreCase("pie")) { 
// 初 始 化 饼 状 图 


else if (type.equalsIignoreCase("line")) { 
// 初 始 化 折线 图 
} 
} 


public void display() { 
if (this.type.equalsIignoreCase("histogram")) { 


// 显 示 柱 状 图 

} 

else if (this.type.equalsIgnoreCase("pie")) { 
// 显 示人 饼 状 图 


else if (this.type.equalsIgnoreCase("line")) { 
// 显 示 折 线 图 
} 
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客户 端 代码 通过 调用 Chart 类 的 构造 函数 来 创建 图 表 对 象 ， 根 据 参数 type 的 不 同 可 以 得 到 不 同 
类 型 的 图 表 ， 然 后 再 调用 display() 方 法 来 显示 相应 的 图 表 。 


不 难看 出 ，Chart 类 是 一 个 “巨大 的 ”类 ， 在 该 类 的 设计 中 存在 如 下 几 个 问题 : 


(1) 在 Chart 类 中 包含 很 多 “jif...else...” 代 码 块 ， 整 个 类 的 代码 相当 完 长 ， 代 码 越 长 ， 阅 读 难 度 、 
维护 难度 和 测试 难度 也 越 大 ; 而 且 大 量 条 件 语句 的 存在 还 将 影响 系统 的 性 能 ， 程 序 在 执行 过 
程 中 需要 做 大 量 的 条 件 判 断 。 


(2) Chart 类 的 职责 过 重 ， 它 负责 初始 化 和 显示 所 有 的 图 表 对 象 ， 将 各 种 图 表 对 象 的 初始 化 代码 
和 显示 代码 集中 在 一 个 类 中 实现 ， 违 反 了 “单一 职责 原则 ”， 不 利于 类 的 重用 和 维护 ; 而 且 将 大 
量 的 对 象 初始 化 代码 都 写 在 构造 函数 中 将 导致 构造 函数 非常 庞大 ， 对 象 在 创建 时 需要 进行 条 
件 判断 ， 降 低 了 对 象 创建 的 效率 。 


(3) 当 需 要 增加 新 类 型 的 图 表 时 ， 必 须 修改 Chart 类 的 源 代码 ， 违 反 了 “ 开 闭 原则 ”。 
与 


(4) 客户 端 只 能 通过 new 关 键 字 来 直接 创建 Chart 对 象 ，Chart 类 与 客户 端 类 耦合 度 较 高 ， 对 象 的 


创建 和 使 用 无 法 分 离 。 


(5) 客户 端 在 创建 Chart 对 象 之 前 可 能 还 需要 进行 大 量 初 始 化 设置 ， 例 如 设置 柱状 图 的 颜色 、 高 
度 等 ， 如 果 在 Chart 类 的 构造 函数 中 没有 提供 一 个 默认 设置 ， 那 就 只 能 由 客户 端 来 完成 初始 设 
置 ， 这 些 代 码 在 每 次 创建 Chart 对 象 时 都 会 出 现 ， 导 致 代码 的 重复 。 


面 对 一 个 如 此 巨大 、 职 责 如 此 重 ， 且 与 客户 端 代码 耦合 度 非常 高 的 类 ， 我 们 应 该 怎么 办 ? 本 
章 将 要 介绍 的 简单 工厂 模式 将 在 一 定 程度 上 解决 上 述 问 题 。 


为 什么 要 引入 工厂 类 ， 大 家 可 参见 : 创建 对 象 与 使 用 对 谈 谈 工厂 的 作用 。 
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2 简单 工厂 模式 概述 


简单 工厂 模式 并 不 属于 GoF 23 个 经 典 设计 模式 ， 但 通常 将 它 作为 学 习 其 他 工厂 模式 的 基础 ， 
它 的 设计 思想 很 简单 ， 其 基本 流程 如 下 : 


首先 将 需要 创建 的 各 种 不 同 对 象 (例如 各 种 不 同 的 Chart 对 象 ) 的 相关 代码 封装 到 不 同 的 类 
中 ， 这 些 类 称 为 具体 产品 类 ， 而 将 它们 公共 的 代码 进行 抽象 和 提取 后 封装 在 一 个 抽象 产品 类 
中 ， 每 一 个 具体 产品 类 都 是 抽象 产品 类 的 子 类 ; 然后 提供 一 个 工厂 类 用 于 创建 各 种 产品 ， 在 
工厂 类 中 提供 一 个 创建 产品 的 工厂 方法 ， 该 方法 可 以 根据 所 传 入 的 参数 不 同 创建 不 同 的 具体 
产品 对 象 ; 客户 端 只 需 调用 工厂 类 的 工厂 方法 并 传 入 相应 的 参数 即 可 得 到 一 个 产品 对 象 。 


简单 工厂 模式 定义 如 下 : 


简单 工厂 模式 (Simple Factory Pattern) : 定义 一 个 工厂 类 ， 它 可 以 根据 参数 的 不 同 返 回 不 同类 的 
实例 ， 被 创建 的 实例 通常 都 具有 共同 的 父 类 。 因 为 在 简单 工厂 模式 中 用 于 创建 实例 的 方法 是 
静态 (static) 方 法 ， 因 此 简单 工厂 模式 又 被 称 为 静态 工厂 方法 (Static Factory Method) 模 式 ， 它 属 
于 类 创建 型 模式 。 


简单 工厂 模式 的 要 点 在 于 : 当 你 需要 什么 ， 只 需要 传 入 一 个 正确 的 参数 ， 就 可 以 获取 你 所 需 


要 的 对 象 ， 而 无 须知 道 其 创建 细节 。 简 单 工厂 模式 结构 比较 简单 ， 其 核心 是 工厂 类 的 设计 ， 
其 结构 如 图 1 所 示 : 


ConcreteProductB 
if(arg.equalslgnoreCase("A")) { | 


retum new ConcreteProductA() 





} 

else if(arg.equalslgnoreCase("B")) { 
retum new Conc reteProductB() 

} 

else{ 


} 





+ factoryMethod (String arg) : Product 


图 1 简单 工厂 模式 结构 图 
在 简单 工厂 模式 结构 图 中 包含 如 下 几 个 角色 : 


@ Factory (工厂 角色 ) : 工厂 角色 即 工厂 类 ， 它 是 简单 工厂 模式 的 核心 ， 负 责 实 现 创建 所 有 产 
品 实例 的 内 部 逻辑 ; 工厂 类 可 以 被 外 界 直接 调用 ， 创 建 所 需 的 产品 对 象 ; 在 工厂 类 中 提供 了 
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静态 的 工厂 方法 factoryMethod0， 它 的 返回 类 型 为 抽象 产品 类 型 Product。 


e Product (抽象 产品 角色 ) : 它 是 工厂 类 所 创建 的 所 有 对 象 的 父 类 ， 封 装 了 各 种 产品 对 象 的 
公有 方法 ， 它 的 引入 将 提高 系统 的 灵活 性 ， 使 得 在 工厂 类 中 只 需 定义 一 个 通用 的 工厂 方法 ， 
因为 所 有 创建 的 具体 产品 对 象 都 是 其 子 类 对 象 。 


e@ ConcreteProduct (具体 产品 角色 ) : 它 是 简单 工厂 模式 的 创建 目标 ， 所 有 被 创建 的 对 象 都 充 
当 这 个 角色 的 某 个 具体 类 的 实例 。 每 一 个 具体 产品 角色 都 继承 了 抽象 产品 角色 ， 需 要 实现 在 
抽象 产品 中 声明 的 抽象 方法 。 


在 简单 工厂 模式 中 ， 客 户 端 通过 工厂 类 来 创建 一 个 产品 类 的 实例 ， 而 无 须 直 接 使 用 new 关 键 字 
来 创建 对 象 ， 它 是 工厂 模式 家 族 中 最 简单 的 一 员 。 


在 使 用 简单 工厂 模式 时 ， 首 先 需 要 对 产品 类 进行 重 构 ， 不 能 设计 一 个 包罗 万 象 的 产品 类 ， 而 
需 根据 实际 情况 设计 一 个 产品 层次 结构 ， 将 所 有 产品 类 公共 的 代码 移 至 抽 痊 产品 类 ， 并 在 抽 
象 产品 类 中 声明 一 些 抽象 方法 ， 以 供 不 同 的 具体 产品 类 来 实现 ， 典 型 的 抽象 产品 类 代码 如 下 
所 示 : 


abstract class Product { 
// 所 有 产品 类 的 公共 业务 方法 
public void methodSame() { 
// 公 共 方 法 的 实现 
} 


// 声 明 抽 象 业 务 方法 
public abstract void methodDiff(); 
} 


在 具体 产品 类 中 实现 了 抽象 产品 类 中 声明 的 抽象 业务 方法 ， 不 同 的 具体 产品 类 可 以 提供 不 同 
的 实现 ， 典 型 的 具体 产品 类 代码 如 下 所 示 : 


class ConcreteProduct extends Product { 
// 实 现 业 务 方法 
public void methodDiff() { 
// 业 务 方法 的 实现 
} 
} 


简单 工厂 模式 的 核心 是 工厂 类 ， 在 没有 工厂 类 之 前 ， 客 户 端 一 般 会 使 用 new 关 键 字 来 直接 创建 
产品 对 象 ， 而 在 引入 工厂 类 之 后 ， 容 户 端 可 以 通过 工厂 类 来 创建 产品 ， 在 简单 工厂 模式 中 ， 
工厂 类 提供 了 一 个 静态 工厂 方法 供 客 户 端 使 用 ， 根 据 所 传 入 的 参数 不 同 可 以 创建 不 同 的 产品 
对 象 ， 典 型 的 工厂 类 代码 如 下 所 示 : 


class Factory { 
// 静 态 工 厂 方法 
public static Product getProduct(String arg) { 
Product product = null; 
if (arg.equalsIgnoreCase("A")) { 
product = new ConcreteProductA(); 
// 初 始 化 设置 product 


else if (arg.equalsIgnoreCase("B")) { 
product = new ConcreteProductB(); 
// 初 始 化 设置 product 
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} 


return product,; 


} 
在 客户 端 代码 中 ， 我 们 通过 调用 工厂 类 的 工厂 方法 即 可 得 到 产品 对 象 ， 典 型 代码 如 下 所 示 : 


class Client { 
public static void main(String args[]) { 
Product product 
product = Factory.getProduct("A"); // 通 过 工厂 类 创建 产品 对 象 
product .methodSame( ); 
product.methodDiff(); 
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3 完整 解决 方案 


为 了 将 Chart 类 的 职责 分 离 ， 同 时 将 Chart 对 象 的 创建 和 使 用 分 离 ，Sunny 软 件 公司 开发 人 员 决 
定 使 用 简单 工厂 模式 对 图 表 库 进行 重 构 ， 重 构 后 的 结构 如 图 2 所 示 : 


+ display () : void 
A 





HistogramChart LineChart 
+ HistogramChart () : 


+ LineChart () 
+ display () : void 


: [+ display() :void 


| 
| 
| 
| .> <<create>> |+ Piechar () 
| 
| 
| 














+ display () :void 


<<create>> 


| et 





图 2 图 表 库 结构 图 


在 图 2 中 ，Chart 接 口 充当 抽象 产品 类 ， 其 子 类 HistogramChart、PieChart 和 LineChart 充 当 具 体 产 
品类 ，ChartFactory 充 当 工 厂 类 。 完 整 代码 如 下 所 示 : 


// 抽 象 图 表 接 口 : 抽象 产品 类 
Interface Chart { 

public void display(); 
} 


// 柱 状 图 类 : 具体 产品 类 
class HistogramChart implements Chart { 
public HistogramChart() { 
System.out.println(" 创 建 柱 状 图 ! ")， 
} 


public void display() { 
System.out.println(" 显 示 柱 状 图 ! "); 
} 
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// 饼 状 图 类 : 具体 产品 类 
class PieChart implements Chart { 
public PieChart() { 
System,.,out .println(" 创 建 饼 状 图 ! "); 
} 


public void display() { 
System,out.println(" 显 示人 饼 状 图 1 "); 
} 


} 


// 折 线 图 类 : 具体 产品 类 
class LineChart implements Chart { 
public LineChart() { 
System,out.println(" 创 建 折线 图 1 "); 
} 


public void display() { 
System,.out,.printlLn(" 显 示 折 线 图 1")， 
} 


} 


// 图 表 工 厂 类 : 工厂 类 
class ChartFactory { 
// 静 态 工 厂 方法 
public static Chart getChart(String type) { 

Chart chart = null; 

If (type.equalsIgnoreCase("histogram")) { 
chart = new HistogramChart(); 
System.out.println(" 初 始 化 设置 柱状 图 |! ")， 

} 

else if (type.equalsIignoreCase("pie")) { 
chart = new PieChart(); 
System.out.println(" 初 始 化 设置 饼 状 图 ! ")， 

} 

else if (type.equalsIgnoreCase("line")) { 
chart = new LineChart(); 
System.out.,println(" 初 始 化 设置 折线 图 | ")， 

} 


return chart,; 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
Chart chart; 


chart = ChartFactory.getchart("histogram"); // 通 过 静态 工厂 方法 多 


chart.display(); 
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编译 并 运行 程序 ， 输 出 结果 如 下 : 
创建 柱状 图 ! 
初始 化 设置 柱状 图 ! 

显示 柱状 图 ! 


在 客户 端 测 试 类 中 ， 我 们 使 用 工厂 类 的 静态 工厂 方法 创建 产品 对 象 ， 如 果 需 要 更 换 产品 ， 只 
需 修改 静态 工厂 方法 中 的 参数 即 可 ， 例 如 将 柱状 图 改 为 饼 状 图 ， 只 需 将 代码 : 


chart = ChartFactory.getCchart("histogram"); 
改 为 : 

chart = ChartFactory.getchart("pie"),; 
编译 并 运行 程序 ， 输 出 结果 如 下 : 

创建 饼 状 图 ! 


初始 化 设置 饼 状 图 ! 
显示 人 饼 状 图 ! 
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4 方案 的 改进 


Sunny 软 件 公司 开发 人 员 发 现在 创建 具体 Chart 对 象 时 ， 每 更 换 一 个 Chart 对 象 都 需要 修改 客户 
端 代码 中 静态 工厂 方法 的 参数 ， 客 户 端 代码 将 要 重新 编译 ， 这 对 于 客户 端 而 言 ， 违 反 了 “ 开 闭 
原则 ”， 有 没有 一 种 方法 能 够 在 不 修改 客户 端 代码 的 前 提 下 更 换 具体 产品 对 象 呢 ? 答案 是 肯定 
的 ， 下 面 将 介绍 一 种 常用 的 实现 方式 。 


我 们 可 以 将 静态 工厂 方法 的 参数 存储 在 XML 或 properties 格 式 的 配置 文件 中 ， 如 下 config.xml 所 
示 : 


<?xml1 version="1.0"?> 

<config> 
<chartType>histogram</chartType> 

</config> 


再 通过 一 个 工具 类 XMLUtil 来 读 取 配 置 文件 中 的 字符 串 参 数 ，XMLUtil 类 的 代码 如 下 所 示 : 


import javax.xml.parsers.*,; 
import org.w3c.dom.*; 

import org.xml.sax.SAXException; 
import java.io.*,; 


public class XMLUtil { 
// 该 方法 用 于 从 XML 配 置 文件 中 提取 图 表 类 型 ， 并 返回 类 型 名 
public static String getChartType() { 
try { 

// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory.newDocumentBuilder(); 
Document doc; 
doc = builder.parse(new File("config.xml")); 


// 获 取 和 包含 图 表 类 型 的 文本 节点 
NodeList nl = doc.getElementsByTagName("chartType"); 
Node classNode = nil.item(0).getFirstcChild(); 
String chartType = classNode.getNodevalue().trim(); 
return chartType; 
} 
catch(Exception e) { 
e,printStackTrace( ); 
return null; 


} 
在 引入 了 配置 文件 和 工具 类 XMLUtil 之 后 ， 客 户 端 代码 修改 如 下 : 
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class Client { 
public static void main(String args[]) { 
Chart chart; 
String type = XMLUtil.getchartType(); // 读 取 配 置 文件 中 的 参数 
chart = ChartFactory.getChart(type); // 创 建 产 品 对 旬 
chart.display(); 


} 


不 难 发 现 ， 在 上 述 客 户 端 代码 中 不 包含 任何 与 具体 图 表 对 象 相关 的 信息 ， 如 果 需 要 更 换 具 体 
图 表 对 象 ， 只 需 修改 配置 文件 config.xml， 无 须 修改 任何 源 代码 ， 符 合 “ 开 闭 原则 ”。 


思考 


在 简单 工厂 模式 中 增加 新 的 具体 产品 时 是 否 符 合 “ 开 闭 原则 ”? 如 果 不 符合 ， 原 有 系统 需 作 
出 哪些 修改 ? 


5 简单 工厂 模式 的 简化 
有 时 候 ， 为 了 简化 简单 工厂 模式 ， 我 们 可 以 将 抽象 产品 类 和 工厂 类 合并 ， 将 静态 工厂 方法 移 
至 抽象 产品 类 中 ， 如 图 3 所 示 : 








ConcreteProductB 






图 3 简化 的 简单 工厂 模式 


在 图 3 中 ， 客 户 端 可 以 通过 产品 父 类 的 静态 工厂 方法 ， 根 据 参 数 的 不 同 创建 不 同类 型 的 产品 子 
类 对 象 ， 这 种 做 法 在 JDK 等 类 库 和 框架 中 也 广泛 存在 。 


6 简单 工厂 模式 总 结 


简单 工厂 模式 提供 了 专门 的 工厂 类 用 于 创建 对 象 ， 将 对 象 的 创建 和 对 象 的 使 用 分 离开 ， 它 作 
为 一 种 最 简单 的 工厂 模式 在 软件 开发 中 得 到 了 较为 广泛 的 应 用 。 


1. 主要 优点 
简单 工厂 模式 的 主要 优点 如 下 : 
(1) 工厂 类 包含 必要 的 判断 逻辑 ， 可 以 决定 在 什么 时 候 创 建 哪 一 个 产品 类 的 实例 ， 客 户 端 可 以 
免除 直接 创建 产品 对 象 的 职责 ， 而 仅仅 “消费 > 产品， 简单 工厂 模式 实现 了 对 象 创 建 和 使 用 的 分 
离 o 
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(2) 客户 端 无 须知 道 所 创建 的 具体 产品 类 的 类 名 ， 只 需要 知道 具体 产品 类 所 对 应 的 参数 即 可 ， 
对 于 一 些 复杂 的 类 名 ， 通 过 简单 工厂 模式 可 以 在 一 定 程度 减少 使 用 者 的 记忆 量 。 


(3) 通过 引入 配置 文件 ， 可 以 在 不 修改 任何 客户 端 代码 的 情况 下 更 换 和 增加 新 的 具体 产品 类 ， 
在 一 定 程度 上 提高 了 系统 的 灵活 性 。 


1. 主要 缺点 
简单 工厂 模式 的 主要 缺点 如 下 : 


(1) 由 于 工厂 类 集中 了 所 有 产品 的 创建 逻辑 ， 职 责 过 重 ， 一 旦 不 能 正常 工作 ， 整 个 系统 都 要 受 
到 景  o 向 办 


(2) 使 用 简单 工厂 模式 势必 会 增加 系统 中 类 的 个 数 (引入 了 新 的 工厂 类 ) ， 增 加 了 系统 的 复杂 
度 和 理解 难度 。 


(3) 系统 扩展 困难 ， 一 旦 添加 新 产品 就 不 得 不 修改 工厂 逻辑 ， 在 产品 类 型 较 多 时 ， 有 可 能 造成 
工厂 逻辑 过 于 复杂 ， 不 利于 系统 的 扩展 和 维护 。 


(4) 简单 工厂 模式 由 于 使 用 了 静态 工厂 方法 ， 造 成 工厂 角色 无 法 形成 基于 继承 的 等 级 结构 。 
适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 简单 工厂 模式 : 


(1) 工厂 类 负责 创建 的 对 象 比 较 少 ， 由 于 创建 的 对 象 较 少 ， 不 会 造成 工厂 方法 中 的 业务 逻辑 太 
过 复杂 。 


(2) 客户 端 只 知道 传 入 工厂 类 的 参数 ， 对 于 如 何 创 建 对 象 并 不 关心 。 
练习 
使 用 简单 工厂 模式 设计 一 个 可 以 创建 不 同 几 何 形状 (如 圆 形 、 方 形 和 三 角形 等 ) 的 绘 


工具 ， 每 个 几何 图 形 都 具有 绘制 draw() 和 擦 除 erase() 两 个 方法 ， 要 求 在 绘制 不 支持 的 和 
图 形 时 ， 提 示 一 个 UnSupportedShapeException 。 
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工厂 方法 模式 -Factory Method Pattern 【学 习 难 度 : 妈妈 六 充 交 ， 使 用 频率 : 克 交 交友 克 】 


e。 工厂 方法 模式 -Factory Method Pattern 
5 省 三 三 兄弟 之 工矿 入 法 准 或 【一 
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人 
TT 7 (3) 


简单 工厂 模式 虽然 简单 ， 但 存在 一 个 很 严重 的 问题 。 当 系统 中 需要 引入 新 产品 时 ， 由 于 静态 
工厂 方法 通过 所 传 入 参数 的 不 同 来 创建 不 同 的 产品 ， 这 必定 要 修改 工厂 类 的 源 代码 ， 将 韦 
背 “ 开 闭 原 则 ”， 如 何 实 现 增加 新 产品 而 不 影响 已 有 代码 ? 工厂 方法 模式 应 运 而 生 ， 本 文 将 介绍 
第 二 种 工厂 模式 一 一 工厂 方法 模式 。 





1 日 志 记 录 器 的 设计 


Sunny 软 件 公司 欲 开 发 一 个 系统 运行 日 志 记 录 器 (Logger)， 该 记录 器 可 以 通过 多 种 途径 保存 系 
统 的 运行 日 志 ， 如 通过 文件 记录 或 数据 库 记 录 ， 用 户 可 以 通过 修改 配置 文件 灵活 地 更 换 日 志 
记录 方式 。 在 设计 各 类 日 志 记 录 器 时 ，Sunny 公 司 的 开发 人 员 发 现 需要 对 日 志 记 录 器 进行 一 些 
初始 化 工作 ， 初 始 化 参数 的 设置 过 程 较为 复杂 ， 而 且 某 些 参数 的 设置 有 严格 的 先后 次 序 ， 否 
则 可 能 会 发 生 记 录 失 败 。 如 何 封 装 记录 器 的 初始 化 过 程 并 保证 多 种 记录 器 切换 的 灵活 性 是 
Sunny 公 司 开发 人 员 面 临 的 一 个 难题 。 


Sunny 公 司 的 开发 人 员 通 过 对 该 需求 进行 分 析 ， 发 现 该 日 志 记 录 器 有 两 个 设计 要 点 : 

(1) 需要 封装 日 志 记录 器 的 初始 化 过 程 ， 这 些 初始 化 工作 较为 复杂 ， 例 如 需要 初始 化 其 他 相关 
的 类 ， 还 有 可 能 需要 读 取 配 置 文件 (例如 连接 数据 库 或 创建 文件 ) ， 导 致 代码 较 长 ， 如 果 将 
它们 都 写 在 构造 函数 中 ， 会 导致 构造 函数 庞大 ， 不 利于 代码 的 修改 和 维护 ; 


(2) 用 户 可 能 需要 更 换 日 志 记 录 方 式 ， 在 客户 端 代码 中 需要 提供 一 种 灵活 的 方式 来 选择 日 志 记 
录 器 ， 尽 量 在 不 修改 源 代 码 的 基础 上 更 换 或 者 增加 日 志 记录 方式 。 


Sunny 公 司 开发 人 员 最 初 使 用 简单 工厂 模式 对 日 志 记 录 器 进行 了 设计 ， 初 始 结构 如 图 1 所 示 : 





FileLogger : DatabaseLogger 
+ WriteLog () : void + WriteLog () : voi 





图 1 基于 简单 工厂 模式 设计 的 日 志 记 录 器 结构 图 


在 图 1 中 ，LoggerFactory 充 当 创 建 日 志 记 录 器 的 工厂 ， 提 供 了 工厂 方法 createLogger() 用 于 创建 
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日 志 记 录 器 ，Logger 是 抽象 日 志 记 录 器 接口 ， 其 子 类 为 具体 日 志 记 录 器 。 其 中 ， 工 厂 类 
LoggerFactory 代 码 片 段 如 下 所 示 : 


// 日 志 记 录 器 工厂 
class LoggerFactory { 
// 静 态 工 厂 方法 
public static Logger createLogger(String args) { 
if(args.equalsIgnoreCase("db")) { 
// 连 接 数 据 库 ， 代 码 省 略 
// 创 建 数据 库 日 志 记 录 器 对 象 
Logger logger = new DatabaseLogger( ); 
// 初 始 化 数据 库 日 志 记 录 器 ， 代 码 省 略 
return logger; 


else “arg eq rr Ar ees Pu Ee) { 
// 创 建 日 志文 件 
// 创 建文 件 日 志 记录 器 对 象 
Logger Legger = new FileLogger(); 
// 初 始 化 文件 日 志 记 录 器 ， 代 码 省 略 
return logger; 


} 
else { 

return null; 
} 


} 


为 了 突出 设计 重点 ， 我 们 对 上 述 代 码 进 行 了 简化 ， 省 略 了 具体 日 志 记 录 器 类 的 初始 化 代码 。 
在 LoggerFactory 类 中 提供 了 静态 工厂 方法 createLogger()， 用 于 根据 所 传 入 的 参数 创 人 同 
类 型 的 日 志 记 录 器 。 通 过 使 用 简 CT 我 们 将 日 志 记 录 器 对 象 的 创建 和 使 用 分 

户 端 只 需 使 用 由 工厂 类 创建 的 日 志 记 录 器 对 象 即 可 ， 无 须 关 心 对 象 的 创建 过 程 ， 人 
现 ， 虽 然 简单 工厂 模式 实现 了 对 象 的 创建 和 使 用 分 离 ， 但 是 仍然 存在 如 下 两 个 问题 : 


(1) 工厂 类 过 于 庞大 ， 包 含 了 大 量 的 许 ...else.…. 代 码 ， 寻 致 维护 和 测试 难度 增 大 ; 


(2) 系统 扩展 不 灵活 ， 如 果 增加 新 类 型 的 日 志 记录 器 ， 必 须 修改 静态 工厂 方法 的 业务 远 辑 ， 韦 
反 了 “ 开 闭 原则 ”。 


如 何 解 决 这 两 个 问题 ， 提 供 一 种 简单 工厂 模式 的 改进 方案 ? 这 就 是 本 文 所 介绍 的 工厂 方法 模 
式 的 动机 之 一 。 
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2 工厂 方法 模式 概述 


在 简单 工厂 模式 中 只 提供 一 个 工厂 类 ， 该 工厂 类 处 于 对 产品 类 进行 实例 化 的 中 心 位 置 ， 它 需 
要 知道 每 一 个 产品 对 人 象 的 创建 细节 ， 并 决定 何 时 实例 化 哪 一 个 产品 类 。 简 单 工厂 模式 最 大 的 
缺点 是 当 有 新 产品 要 加 入 到 系统 中 时 ， 必 须 修改 工厂 类 ， 需 要 在 其 中 加 入 必要 的 业务 逻辑 ， 
这 违背 了 “ 开 闭 原则 ”。 此 外 ， 在 简单 工厂 模式 中 ， 所 有 的 产品 都 由 同一 个 工厂 创建 ， 工 厂 类 职 
责 较 重 ， 业 务 逻 辑 较 为 复杂 ， 具 体 产 品 与 工厂 类 之 间 的 耦合 度 高 ， 严 重 影响 了 系统 的 灵活 性 
和 扩展 性 ， 而 工厂 方法 模式 则 可 以 很 好 地 解决 这 一 问题 。 


在 工厂 方法 模式 中 ， 我 们 不 再 提供 一 个 统一 的 工厂 类 来 创建 所 有 的 产品 对 象 ， 而 是 针对 不 同 
的 产品 提供 不 同 的 工厂 ， 系 统 提 供 一 个 与 产品 等 级 结构 对 应 的 工厂 等 级 结构 。 工 厂 方法 模式 
定义 如 下 : 


工厂 方法 模式 (Factory Method Pattern) : 定义 一 个 用 于 创建 对 象 的 接口 ， 让 子 类 决定 将 哪 一 个 
类 实例 化 。 工 厂 方 法 模式 让 一 个 类 的 实例 化 延迟 到 其 子 类 。 工 厂 方 法 模式 又 简称 为 工厂 模式 
(Factory Pattern)， 又 可 称 作 虚拟 构造 器 模式 (Virtual Constructor Pattern) 或 多 态 工厂 模式 
(Polymorphic Factory Pattern)。 工 厂 方法 模式 是 一 种 类 创建 型 模式 。 


工厂 方法 模式 提供 一 个 抽象 工厂 接口 来 声明 抽象 工厂 方法 ， 而 由 其 子 类 来 具体 实现 工厂 方 
法 ， 创 建 具体 的 产品 对 象 。 工 厂 方法 模式 结构 如 图 2 所 示 : 





+ factoryMethod () 
八 













ConcreteProduct 


ConcreteFactory 


+ factoryMethod () 


| 
return new ConcreteProduct(); 


图 2 工厂 方法 模式 结构 图 
在 工厂 方法 模式 结构 图 中 包含 如 下 几 个 角色 : 


e Product (抽象 产品 ) : 它 是 定义 产品 的 接口 ， 是 工厂 方法 模式 所 创建 对 象 的 超 类 型 ， 也 就 
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是 产品 对 象 的 公共 父 类 。 


e@ ConcreteProduct (具体 产品 ) : 它 实现 了 抽象 产品 接口 ， 某 种 类 型 的 具体 产品 由 专门 的 具体 
工厂 创建 ， 具 体 工 厂 和 具体 产品 之 间 一 一 对 应 。 


@ Factory (抽象 工厂 ) : 在 抽象 工厂 类 中 ， 声 明了 工厂 方法 (Factory Method)， 用 于 返回 一 个 
产品 。 抽 象 工厂 是 工厂 方法 模式 的 核心 ， 所 有 创建 对 象 的 工厂 类 都 必须 实现 该 接口 。 


e ConcreteFactory (具体 工厂 ) : 它 是 抽象 工厂 类 的 子 类 ， 实 现 了 抽象 工厂 中 定义 的 工厂 方 
法 ， 并 可 由 客户 端 调用 ， 返 回 一 个 具体 产品 类 的 实例 。 


与 简单 工厂 模式 相 比 ， 工 厂 方法 模式 最 重要 的 区 别 是 引入 了 抽象 工厂 角色 ， 抽 象 工厂 可 以 是 
接口 ， 也 可 以 是 抽象 类 或 者 具体 类 ， 其 典型 代码 如 下 所 示 : 


Interface Factory { 
public Product factoryMethod () ， 
} 


在 抽象 工厂 中 声明 了 工厂 方法 但 并 未 实现 工厂 方法 ， 具 体 产品 对 象 的 创建 由 其 子 类 负责 ， 客 
户 端 针 对 抽象 工厂 编程 ， 可 在 运行 时 再 指定 具体 工厂 类 ， 具 体 工厂 类 实现 了 工厂 方法 ， 不 同 
的 具体 工厂 可 以 创建 不 同 的 具体 产品 ， 其 典型 代码 如 下 所 示 : 


class ConcreteFactory implements Factory { 
public Product factoryMethod() { 
return new ConcretepProduct() ， 
} 


} 


在 实际 使 用 时 ， 具 体 工厂 类 在 实现 工厂 方法 时 除了 创建 具体 产品 对 象 之 外 ， 还 可 以 负责 产品 
对 象 的 初始 化 工作 以 及 一 些 资源 和 环境 配置 工作 ， 例 如 连接 数据 库 、 创 建文 件 等 。 


在 客户 端 代 码 中 ， 只 需 关 心 工厂 类 即 可 ， 不 同 的 具体 工厂 可 以 创建 不 同 的 产品 ， 典 型 的 客户 
端 类 代码 片段 如 下 所 示 : 


Factory factory; 

factory = new ConcreteFactory(); // 可 通过 配置 文件 实现 
Product product; 

product = factory.factoryMethod( ); 


可 以 通过 配置 文件 来 存储 具体 工厂 类 ConcreteFactory 的 类 名 ， 更 换 新 的 具体 工厂 时 无 须 修改 源 
代码 ， 系 统 扩展 更 为 方便 。 


' 考 
工厂 方法 模式 中 的 工厂 方法 能 否 为 静态 方法 ?为 什么 ? 
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3 完整 解决 方案 
Sunny 公 司 开 发 人 员 决 定 使 用 工厂 方法 模式 来 设计 日 志 记 录 器 ， 其 基本 结构 如 图 3 所 示 : 


Ea 








LoggerFactory 


+ WriteLog () : void 
Ld TS 





+ CreateLogger () : Logger 


A 


FileLogger : : DatabaseL ogger 


FileLoggerFactory 攻 : DatabaseLoggerFactory 





+ CreateLogger () : Logger + createLogger () : Logger 





图 3 日志 记 录 器 结构 图 


在 图 3 中 ，Logger 接 口 充当 抽象 产品 ， 其 子 类 FileLogger 和 DatabaseLogger 充 当 具 体 产 品 ， 
LoggerFactory 接 口 充当 抽象 工厂 ， 其 子 类 FileLoggerFactory 和 DatabaseLoggerFactory 充 当 具 体 
工厂 。 完 整 代码 如 下 所 示 : 


// 日 志 记 录 器 接口 : 抽象 产品 
Interface Logger { 
public void writeLog(); 


} 


// 数 据 库 日 志 记 录 器 : 具体 产品 
class DatabaseLogger implements Logger { 
public void writeLog() { 
System.out.println(" 数 据 库 日 志 记 录 。"); 
} 


} 


// 文 件 日 志 记 录 器 : 具体 产品 
class FileLogger implements Logger { 
public void writeLog() { 
System.out.println(" 文 件 日 志 记 录 。")， 
} 


} 


// 日 志 记 录 器 工厂 接口 : 抽象 工厂 
interface LoggerFactory { 
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public Logger createLogger(); 
} 


// 数 据 库 日 志 记 录 器 工厂 类 : 具体 工厂 
class DatabaseLoggerFactory implements LoggerFactory { 
public Logger createLogger() { 
// 连 接 数据 库 ， 代 码 省 略 
// 创 建 数据 库 日 志 记 录 器 对 象 
Logger logger = new DatabaseLogger(); 
// 初 始 化 数据 库 日 志 记 录 器 ， 代 码 省 略 
return logger; 


} 


// 文 件 日 志 记 录 器 工厂 类 : 具体 工厂 
class FileLoggerFactory implements LoggerFactory { 
public Logger Erealel oggert) { 
// 创 建文 件 日 志 记 录 器 对 象 
Logger logger = new FileLogger(); 
// 创 建文 件 ， 代 码 省 略 
return logger; 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
LoggerFactory factory; 
Logger logger; 
factory = new FileLoggerFactory(); // 可 引入 配置 文件 实现 
logger = factory.createLogger(); 
logger .writeLog(); 


} 

编译 并 运行 ， 输出 结果 如 下 : 
文件 日 志 记 录 。 

4 反射 与 配置 文件 


为 了 让 系统 具有 更 好 的 灵活 性 和 可 扩展 性 ， ，Sunny 公 司 开 发 人 员 决 定 对 日 志 记 录 器 客户 端 代码 
进行 重 构 ， 使 得 可 以 在 不 修改 任何 客户 端 代码 的 基础 上 更 换 或 增加 新 的 日 志 记 录 方 式 。 


在 客户 端 代码 中 将 不 再 使 用 new 关 键 字 来 创建 工厂 对 象 ， 而 是 将 具体 工厂 类 的 类 名 存储 在 配置 
文件 (如 XML 文件 ) 中 ， 通 过 读 取 配 置 文件 获取 类 名 字符 串 ， 再 使 用 Java 的 反射 机 制 ， 根 据 
类 名 字符 串 生 成 对 象 。 在 整个 实现 过 程 中 需要 用 到 两 个 技术 : Java 反 射 机 制 与 配置 文件 读 取 。 
软件 系统 的 配置 文件 通常 为 XML 文件 ， 我 们 可 以 使 用 DOM (Document Object Model)、SAX 

(Simple API for XML)、StAX (Streaming API for XML) 等 技术 来 处 理 XML 文 件 。 关 于 DOM 、 

SAX、StAX 等 技术 的 详细 学 习 大 家 可 以 参考 其 他 相关 资料 ， 在 此 不 了 予 扩展 。 


扩展 
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关于 Java 与 XML 的 相关 资料 ， 大 家 可 以 阅读 Tom Myers 和 Alexander Nakhimovsky 所 著 的 《Java 
XML 编程 指南 》 一 书 或 访问 developer Works 中 国 中 的 “Java XML 技术 专题 ”， 参 考 链 接 : 
http:/www.ibm.com/developerworks/cn/xml/theme/x-java.html 


Java 反 射 (Java Reflection) 是 指 在 程序 运行 时 获取 已 知名 称 的 类 或 已 有 对 象 的 相关 信息 的 一 种 机 
制 ， 包 括 类 的 方法 、 属 性 、 父 类 等 信息 ， 还 包括 实例 的 创建 和 实例 类 型 的 判断 等 。 在 反射 中 
使 用 最 多 的 类 是 Class，Class 类 的 实例 表示 正在 运行 的 Java 应 用 程序 中 的 类 和 接口 ， 其 
forName(String className) 方 法 可 以 返回 与 带 有 给 定 字符 串 名 的 类 或 接口 相关 联 的 Class 对 象 ， 
再 通过 Class 对 象 的 newInstance() 方 法 创建 此 对 象 所 表示 的 类 的 一 个 新 实例 ， 即 通过 一 个 类 名 字 
符 串 得 到 类 的 实例 。 如 创建 一 个 字符 串 类 型 的 对 象 ， 其 代码 如 下 : 


// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName("String"); 
Object obj=c.newInstance( ); 
return obj; 


此 外 ， 在 JDK 中 还 提供 了 java.lang.reflect 包 ， 封 装 了 其 他 与 反射 相关 的 类 ， 此 处 只 用 到 上 述 简 
单 的 反射 代码 ， 在 此 不 予 扩展 。 


Sunny 公 司 开发 人 员 创建 了 如 下 XML 格式 的 配置 文件 config.xml 用 于 存储 具体 日 志 记 录 器 工厂 


类 类 名 : 


<! 一 config.xml --> 

<?xml1 version="1.0"?> 

<config> 
<className>FileLoggerFactory</className> 

</config> 


为 了 读 取 该 配置 文件 并 通过 存储 在 其 中 的 类 名 字符 串 反 射 生成 对 象 ，Sunny 公 司 开发 人 员 开 发 
了 一 个 名 为 XMLUtil 的 工具 类 ， 其 详细 代码 如 下 所 示 : 


// 工 具 类 XMLUti1l .java 

import javax.xml.parsers.*,; 
import org.w3c.dom.*; 

import org.xml.sax.SAXException; 
import java.io.*; 


public class XMLUtil { 
// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 
public static Object getBean( ) { 
try { 

// 创 建 DOM 文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory.newDocumentBuilder(); 
Document doc; 
doc = builder.parse(new File("config.xm]l")); 


// 获 取 包 含 类 名 的 文本 节点 

NodeList nl = doc.getElementsByTagName("className"); 
Node classNode=nl1.item(0).getFirstChild(); 

String cName=classNode.getNodeValue(); 


// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName(cName); 
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Object obj=c,newInstance( ) ; 
return obj 


catch(Exception e) { 
e.printStackTrace( ); 
return null; 


} 


有 了 XMLUtil 类 后 ， 可 以 对 日 志 记 录 器 的 客户 端 代码 进行 修改 ， 不 再 直接 使 用 new 关 键 字 来 创 
建 具体 的 工厂 类 ， 而 是 将 具体 工厂 类 的 类 名 存储 在 XML 文件 中 ， 再 通过 XMLUtil 类 的 静态 工 
厂 方 法 getBean() 方 法 进行 对 象 的 实例 化 ， 代 码 修改 如 下 : 


class Client { 
public static void main(String args[]) { 
LoggerFactory factory; 
Logger logger; 
factory = (LoggerFactory)XMLUtil.getBean(); //getBean() 的 返回 
logger = factory.createLogger(); 
logger .writeLog(); 


} 

引入 XMLUtil 类 和 XML 配置 文件 后 ， 如 果 要 增加 新 的 日 志 记 录 方 式 ， 只 需要 执行 如 下 几 个 步 
又 : 

(1) 新 的 日 志 记 录 器 需要 继承 抽象 日 志 记 录 器 Logger ; 


2 对 应 增加 一 个 新 的 具体 日 志 记 录 器 工厂 ， 继 承 抽象 日 志 记 录 器 工厂 LoggerFactory ， 并 实现 
其 中 的 工厂 方法 createLogger0， 设 置 好 初始 化 参数 和 环境 变量 ， 返 回 具体 日 志 记 录 器 对 象 


(3) 修改 配置 文件 config.xml， 将 新 增 的 具体 日 志 记 录 器 工厂 类 的 类 名 字符 串 替换 原 有 工厂 类 类 

名 字符 串 ; 

人 去 记录 器 类 和 具体 日 志 记 录 器 ee 凡 测 试 类 即 可 使 用 新 的 
志 记 录 方 式 ， 而 原 有 类 库 代 码 无 须 做 任何 修改 ， 完 全 符合 “ 开 闭 原则 ”。 


通过 上 述 重 构 可 以 使 得 系统 更 加 灵活 ， 由 于 很 多 设计 模式 都 关注 系统 的 可 扩展 性 和 灵活 性 ， 
因此 都 定义 了 抽象 层 ， 在 抽象 层 中 声明 业务 方法 ， 而 将 业务 方法 的 实现 放 在 实现 层 中 。 疑问 


本 
心 


有 人 说 : 可 以 在 客户 端 代码 中 直接 通过 反射 机 制 来 生成 产品 对 象 ， 在 定义 产品 对 象 时 使 用 抽 
象 类 型 ， 同 样 可 以 确保 系统 的 灵活 性 和 可 扩展 性 ， 增 加 新 的 具体 产品 类 无 须 修改 源 代码 ， 只 
需要 将 其 作为 抽象 产品 类 的 子 类 再 修改 配置 文件 即 可 ， 根 本 不 需要 抽象 工厂 类 和 具体 工厂 


类 。 


试 思 考 这 种 做 法 的 可 行 性 ? 如 果 可 行 ， 这 种 做 法 是 否 存 在 问题 ?为 什么 ? 
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5 重 载 的 工厂 方法 


Sunny 公 司 开发 人 员 通 过 进一步 分 析 ， 发 现 可 以 通过 多 种 方式 来 初始 化 日 志 记 录 器 ， 例 如 可 以 
为 各 种 日 志 记 录 器 提供 默认 实现 ; 还 可 以 为 数据 库 日 志 记 录 器 提供 数据 库 连 接 字 符 事 ， 为 文 

件 日 志 记 录 器 提供 文件 路 径 ; 也 可 以 将 参数 封装 在 一 个 Object 类 型 的 对 象 中 ， 通 过 Object 对 象 
将 配置 参数 传 入 工厂 类 。 此 时 ， 可 以 提供 一 组 重 载 的 工厂 方法 ， 以 不 同 的 方式 对 产品 对 象 进 

行 创建 。 当 然 ， 对 于 同一 个 具体 工厂 而 言 ， 无 论 使 用 哪个 工厂 方法 ， 创 建 的 产品 类 型 均 要 相 

同 。 如 图 4 所 示 : 


es LoggerFactory 


+ createLogger () : Logger 

+ createLogger (String args) : Logger 

+ createLogger (Object obj) : Logger 
点 六 





FileLoggerFactory DatabaseLoggerFactory 


+ createLogger () : Logger 
+ createLogger (String args) : Logger 
+ createLogger (Object obj) : Logger 


+ createLogger () : Logger 
+ createLogger (String args) : Logger 
+ createLogger (Object obj) : Logger | 





图 4 重 载 的 工厂 方法 结构 图 
引入 重 载 方法 后 ， 抽 象 工厂 LoggerFactory 的 代码 修改 如 下 : 


Interface LoggerFactory { 
public Logger createLogger(); 
public Logger createLogger(String args); 
public Logger createLogger (Object obj); 
} 


具体 工厂 类 DatabaseLoggerFactory 代 码 修改 如 下 : 


class DatabaseLoggerFactory implements LoggerFactory { 
public Logger createLogger() { 
// 使 用 默认 方式 连接 数据 库 ， 代 码 省 略 
Logger logger = new DatabaseLogger(); 
// 初 始 化 数据 库 日 志 记 录 器 ， 代 码 省 略 
return logger; 


} 


public Logger createLogger(String args) { 
// 使 用 参数 argSs 作 为 连接 字符 串 来 连接 数据 库 ， 代 码 省 略 
Logger logger = new DatabaseLogger(); 
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// 初 始 化 数据 库 日 志 记 录 器 ， 代 码 省 略 
return logger; 


} 


public Logger createLogger(Object obj) { 
// 使 用 封装 在 参数 0bj 中 的 连接 字符 串 来 连接 数据 库 ， 代 码 省 略 
Logger logger = new DatabaseLogger(); 
// 使 用 封装 在 参数 0bj 中 的 数据 来 初始 化 数据 库 日 志 记 录 器 ， 代 码 省 略 
return logger; 


} 
// 其 他 具体 工厂 类 代码 省 略 


在 抽象 工厂 中 定义 多 个 重 载 的 工厂 方法 ， 在 具体 工厂 中 实现 了 这 些 工厂 方法 ， 这 些 方法 可 以 
包含 不 同 的 业务 逻辑 ， 以 满足 对 不 同 产品 对 象 的 需求 。 


6 工厂 方法 的 隐藏 

有 时 候 ， 为 了 进一步 简化 客户 端的 使 用 ， 还 可 以 对 客户 端 隐藏 工厂 方法 ， 此 时 ， 在 工厂 类 中 
将 直接 调用 产品 类 的 业务 方法 ， 客 户 端 无 须 调 用 工厂 方法 创建 产品 ， 直 接 通 过 工厂 即 可 使 用 
所 创建 的 对 象 中 的 业务 方法 。 


如 果 对 客户 端 隐藏 工厂 方法 ， 日 志 记 录 器 的 结构 图 将 修改 为 图 5 所 示 : 





| 
LoggerFactory 
{abstract} 


+ CreateLogger () : Logger 
+ WriteLog () :Volid 
2 








+ WriteLog () : void 
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FileLogger : : | DatabaseLogger 
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FileLoggerFactory 


+ CreateLogger () : Logger 


DatabaseLoggerFactory 






图 5 隐藏 工厂 方法 后 的 日 志 记录 器 结构 图 
在 图 5 中 ， 抽 象 工厂 类 LoggerFactory 的 代码 修改 如 下 : 


/V/ 改 为 抽象 类 
abstract class LoggerFactory { 
// 在 工厂 类 中 直接 调用 日 志 记 录 器 类 的 业务 方法 writeLog() 
public void writeLog() { 
Logger logger = this.createLogger(); 
logger .writeLog( ); 


public abstract Logger createLogger(); 
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} 
客户 端 代码 修改 如 下 : 


class Client { 
public static void main(String args[]) { 
LoggerFactory factory; 
factory = (LoggerFactory)XMLUtil.getBean( ); 
factory.writeLog(); // 直 接 使 用 工厂 对 象 来 调用 产品 对 象 的 业务 方法 


} 


通过 将 业务 方法 的 调用 移入 工厂 类 ， 可 以 直接 使 用 工厂 对 象 来 调用 产品 对 象 的 业务 方法 ， 窜 
户 端 无 须 直接 使 用 工厂 方法 ， 在 茶 些 情况 下 我 们 也 可 以 使 用 这 种 设计 方案 。 


7 工厂 方法 模式 总 结 
工厂 方法 模式 是 简单 工厂 模式 的 延伸 ， 它 继承 了 简单 工厂 模式 的 优点 ， 同 时 还 弥补 了 简单 工 


厂 模 式 的 不 足 。 工 厂 方法 模式 是 使 用 频率 最 高 的 设计 模式 之 一 ， 是 很 多 开源 框架 和 API 类 库 的 
核心 模式 。 


1. 主要 优点 
工厂 方法 模式 的 主要 优点 如 下 : 


(1) 在 工厂 方法 模式 中 ， 工 厂 方法 用 来 创建 客户 所 需要 的 产品 ， 同 时 还 向 客户 隐藏 了 哪 种 具体 
产品 类 将 被 实例 化 这 一 细节 ， 用 户 只 需要 关心 所 需 产品 对 应 的 工厂 ， 无 须 关心 创建 细节 ， 其 
至 无 须知 道具 体 产品 类 的 类 名 。 


(2) 基于 工厂 角色 和 产品 角色 的 多 态 性 设计 是 工厂 方法 模式 的 关键 。 它 能 够 让 工厂 可 以 自主 确 
定 创建 何 种 产品 对 象 ， 而 如 何 创建 这 个 对 象 的 细节 则 完全 封装 在 具体 工厂 内 部 。 工 厂 方法 模 
式 之 所 以 又 被 称 为 多 态 工厂 模式 ， 就 正 是 因为 所 有 的 具体 工厂 类 都 具有 同一 抽象 父 类 。 


(3) 使 用 工厂 方法 模式 的 另 一 个 优点 是 在 系统 中 加 入 新 产品 时 ， 无 须 修改 抽象 工厂 和 抽象 产品 
提供 的 接口 ， 无 须 修改 客户 端 9 也 无 须 修 改 其 他 的 具体 工厂 和 具体 产品 ， 而 只 要 添加 一 个 具 
体 工厂 和 具体 产品 就 可 以 了 ， 这 样 ， 系 统 的 可 扩展 性 也 就 变 得 非常 好 ， 完 全 符合 " 开 闭 原则 ”。 


1. 主要 缺点 
工厂 方法 模式 的 主要 缺点 如 下 : 
(1) 在 添加 新 产品 时 ， 需 要 编写 新 的 具体 产品 类 ， 而 且 还 要 提供 与 之 对 应 的 具体 工厂 类 ， 系 统 
中 类 的 个 数 将 成 对 增加 ， 在 一 定 程度 上 增加 了 系统 的 复杂 度 ， 有 更 多 的 类 需要 编译 和 运行 ， 
会 给 系统 带 来 一 些 额 外 的 开销 。 
(2) 由 于 考虑 到 系统 的 可 扩展 性 ， 需 要 引入 抽象 层 ， 在 客户 端 代码 中 均 使 用 抽象 层 进行 定义 ， 
增加 了 系统 的 抽象 性 和 理解 难度 ， 且 在 实现 时 可 能 需要 用 到 DOM、 反 射 等 技术 ， 增 加 了 系统 
的 实现 难度 。 

1. 适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 工厂 方法 模式 : 
(1) 客户 端 不 知道 它 所 需要 的 对 象 的 类 。 在 工厂 方法 模式 中 ， 客 户 端 不 需要 知道 具体 产品 类 的 
类 名 ， 只 需要 知道 所 对 应 的 工厂 即 可 ， 具 体 的 产品 对 象 由 具体 工厂 类 创建 ， 可 将 具体 工厂 类 


的 类 名 存储 在 配置 文件 或 数据 库 中 。 
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(2) 抽象 工厂 类 通过 其 子 类 来 指定 创建 哪个 对 象 。 在 工厂 方法 模式 中 ， 对 于 抽象 工厂 类 只 需要 
提供 一 个 创建 产品 的 接口 ， 而 由 其 子 类 来 确定 具体 要 创建 的 对 象 ， 利 用 面向 对 象 的 多 态 性 和 
里 色 代 换 原 则 ， 在 程序 运行 时 ， 子 类 对 象 将 敌 盖 父 类 对 象 ， 从 而 使 得 系统 更 容易 扩展 。 


练习 
使 用 工厂 方法 模式 设计 一 个 程序 来 读 取 各 种 不 同类 型 的 图 片 格 式 ， 针 对 每 一 种 图 片 格式 都 设 


计 一 个 图 片 读 取 器 ， 如 GIF 图 片 读 取 器 用 于 读 取 GIF 格式 的 图 片 、JPG 图 片 读 取 器 用 于 读 取 JPG 
格式 的 图 片 。 需 充分 考虑 系统 的 灵活 性 和 可 扩展 性 。 
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抽象 工厂 模式 -Abstract Factory Pattern 【学 习 难 度 : 克 克 克 交 六， 使 用 频率 : 次 克 交友 六】 


e 抽象 工厂 模式 -Abstract Factory Pattern 
o 工厂 三 兄弟 之 抽象 工厂 模式 (一 ) 
o 工厂 三 兄弟 之 抽象 工厂 模式 (二) 
o 工厂 三 兄弟 之 抽象 工厂 模式 (三 ) 
o 工厂 三 兄弟 之 抽象 工厂 模式 (四 ) 
9 下 三 三 昂 弟 之 岳 象 开矿 模式 【 王 ) 


Pa i |) 
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工厂 方法 模式 通过 引入 工厂 等 级 结构 ， 解 决 了 简单 工厂 模式 中 工厂 类 职责 太 重 的 问题 ， 但 由 
于 工厂 方法 模式 中 的 每 个 工厂 只 生产 一 类 产品 ， 可 能 会 导致 系统 中 存在 大 量 的 工厂 类 ， 势 必 
会 增加 系统 的 开销 。 此 时 ， 我 们 可 以 考虑 将 一 些 相 关 的 产品 组 成 一 个 “产品 族 ”， 由 同一 个 工厂 
来 统一 生产 ， 这 就 是 我 们 本 文 将 要 学 习 的 抽象 工厂 模式 的 基本 思想 。 


1 界面 皮肤 库 的 初始 设计 


Sunny 软 件 公司 欲 开 发 一 套 界 面皮 肤 库 ， 可 以 对 Java 桌 面 软件 进行 界面 美化 。 为 了 保护 版 权 ， 
该 皮肤 库 源 代码 不 打算 公开 ， 而 只 向 用 户 提供 已 打包 为 jar 文 件 的 class 字 节 码 文件 。 用 户 在 使 
用 时 可 以 通过 菜单 来 选择 皮肤 ， 不 同 的 皮肤 将 提供 视觉 效果 不 同 的 按钮 、 文 本 框 、 组 合 框 等 
界面 元 素 ， 其 结构 示意 图 如 图 1 所 示 : 







Spring 风格 


Summer 风 格 


图 1 界面 皮肤 库 结构 示意 图 


该 皮肤 库 需 要 具备 良好 的 灵活 性 和 可 扩展 性 ， 用 户 可 以 自由 选择 不 同 的 皮肤 ， 开 发 人 员 可 以 
在 不 修改 既 有 代码 的 基础 上 增加 新 的 皮肤 。 


Sunny 软 件 公司 的 开发 人 员 针 对 上 述 要 求 ， 决 定 使 用 工厂 方法 模式 进行 系统 的 设计 ， 为 了 保证 


系统 的 灵活 性 和 可 扩展 性 » 提供 一 系列 有 具体 工厂 来 创 建 按钮 i 文本 框 组 合 框 等 界面 元 素 ” 
客户 端 针 对 抽象 工厂 编程 ， 初 始 结构 如 图 2 所 示 : 
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图 2 基于 工厂 方法 模式 的 界面 皮肤 库 初 始 结构 图 


在 图 2 中 ， 提 供 了 大 量 工厂 来 创建 具体 的 界面 组 件 ， 可 以 通过 配置 文件 更 换 具 体 界 面 组件 从 而 
改变 界面 风格 。 但 是 ， 此 设计 方案 存在 如 下 问题 : 


(1) 当 需 要 增加 新 的 皮肤 时 ， 虽 然 不 要 修改 现 有 代码 ， 但 是 需要 增加 大 量 类 ， 针 对 每 一 个 新 增 
具体 组 件 都 需要 增加 一 个 具体 工厂 ， 类 的 个 数 成 对 增加 ， 这 无 疑 会 导致 系统 越 来 越 席 大 ， 增 
加 系统 的 维护 成 本 和 运行 开销 : 


(2) 由 于 同一 种 风格 的 具体 界面 组 件 通常 要 一 起 显示 ， 因 此 需要 为 每 个 组 件 都 选择 一 个 具体 工 
厂 ， 用 户 在 使 用 时 必须 逐个 进行 设置 ， 如 果 某 个 具体 工厂 选择 失误 将 会 导致 界面 显示 混乱 ， 
虽然 我 们 可 以 适当 增加 一 些 约束 语句 ， 但 客户 端 代码 和 配置 文件 都 较为 复杂 。 


如 何 减少 系统 中 类 的 个 数 并 保证 客户 端 每 次 始终 只 “使 用 某 一 种 风格 的 具体 界面 组 件 ? 这 


Sunny 公 司 开发 人 员 所 面临 的 两 个 问题 ， 显然 ， 工 厂 方法 模式 无 法 解决 这 两 个 问题 ， 别 着 龟 ， 
本 文 所 介绍 的 抽象 工厂 模式 可 以 让 这 些 问题 迎刃而解 。 
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2 产品 等 级 结构 与 产品 族 


在 工厂 方法 模式 中 具体 工厂 负责 生产 具体 的 产品 ， 每 一 个 具体 工厂 对 应 一 种 具体 产品 ， 工 厂 
方法 具有 唯一 性 ， 一 般 情况 下 ， 一 个 具体 工厂 中 只 有 一 个 或 者 一 组 重 载 的 工厂 方法 。 但 是 有 
时 候 我 们 希望 一 个 工厂 可 以 提供 多 个 产品 对 象 ， 而 不 是 单一 的 产品 对 象 ， 如 一 个 电器 工厂 ， 
它 可 以 生产 电视 机 、 电 冰箱 、 空 调 等 多 种 电器 ， 而 不 是 只 生产 某 一 种 电器 。 为 了 更 好 地 理解 
抽象 工厂 模式 ， 我 们 先 引入 两 个 概念 : 


(1) 产品 等 级 结构 : 产品 等 级 结构 即 产品 的 继承 结构 ， 如 一 个 抽象 类 是 电视 机 ， 其 子 类 有 海尔 
电视 机 、 海 信和 电视 机 、TCL 电 视 机 ， 则 抽象 电视 机 与 具体 品牌 的 电视 机 之 间 构 成 了 一 个 产品 等 
级 结构 ， 抽 象 电视 机 是 父 类 ， 而 具体 品牌 的 电视 机 是 其 子 类 。 


(2) 产品 族 : 在 抽象 工厂 模式 中 ， 产 品 族 是 指 由 同一 个 工厂 生产 的 ， 位 于 不 同 产品 等 级 结构 中 
的 一 组 产品 ， 如 海尔 电器 工厂 生产 的 海尔 电视 机 、 海 尔 电 冰 箱 ， 海 尔 电视 机 位 于 电视 机 产品 
等 级 结构 中 ， 海 尔 电 冰箱 位 于 电 冰 箱 产 品 等 级 结构 中 ， 海 尔 电视 机 、 海 尔 电 冰箱 构成 了 一 个 
产品 族 。 


产品 等 级 结构 与 产品 族 示意 图 如 图 3 所 示 : 


一 个 产品 族 






一 个 产品 等 级 结构 


产品 等 级 结构 


图 3 产品 族 与 产品 等 级 结构 示意 图 


在 图 3 中 ， 不 同 颜 色 的 多 个 正方 形 、 圆 形 和 椭圆 形 分 别 构成 了 三 个 不 同 的 产品 等 级 结构 ， 而 相 
同 闫 色 的 正方 形 、 圆 形 和 栅 圆 形 构成 了 一 个 产品 族 ， 每 一 个 形状 对 象 都 位 于 某 个 产品 族 ， 并 
属于 某 个 产品 等 级 结构 。 图 3 中 一 共有 五 个 产品 族 ， 分 属于 三 个 不 同 的 产品 等 级 结构 。 我 们 只 
要 指明 一 个 产品 所 处 的 产品 族 以 及 它 所 属 的 等 级 结构 ， 就 可 以 唯一 确定 这 个 产品 。 


当 系 统 所 提供 的 工厂 生产 的 具体 产品 并 不 是 一 个 简单 的 对 象 ， 而 是 多 个 位 于 不 同 产品 等 级 结 
构 、 属 于 不 同类 型 的 具体 产品 时 就 可 以 使 用 抽 蔓 工厂 模式 。 抽 象 工 厂 模 式 是 所 有 形式 的 工厂 
模式 中 最 为 抽象 和 最 具 一 般 性 的 一 种 形式 。 抽 象 工厂 模式 与 工厂 方法 模式 最 大 的 区 别 在 于 ， 
工厂 方法 模式 针对 的 是 一 个 产品 等 级 结构 ， 而 抽象 工厂 模式 需要 面 对 多 个 产品 等 级 结构 ， 一 
个 工厂 等 级 结构 可 以 负责 多 个 不 同 产品 等 级 结构 中 的 产品 对 象 的 创建 。 当 一 个 工厂 等 级 结构 
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可 以 创建 出 分 属于 不 同 产品 等 级 结构 的 一 个 产品 族 中 的 所 有 对 象 时 ， 抽 象 工厂 模式 比 工厂 方 
法 模式 更 为 简单 、 更 有 效率 。 抽 象 工厂 模式 示意 图 如 图 4 所 示 : 


产品 族 
” 
一 个 具体 工厂 E 
TD 





图 4 抽象 工厂 模式 示意 图 


在 图 4 中 ， 每 一 个 具体 工厂 可 以 生产 属于 一 个 产品 族 的 所 有 产品 ， 例 如 生产 颜色 相同 的 正方 
形 、 圆 形 和 椭圆 形 ， 所 生产 的 产品 又 位 于 不 同 的 产品 等 级 结构 中 。 如 果 使 用 工厂 方法 模式 ， 
图 4 所 示 结 构 需要 提供 15 个 具体 工厂 ， 而 使 用 抽象 工厂 模式 只 需要 提供 5 个 具体 工厂 ， 极 大 减 
少 了 系统 中 类 的 个 数 。 
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3 抽象 工厂 模式 概述 


抽象 工厂 模式 为 创建 一 组 对 象 提供 了 一 种 解决 方案 。 与 工厂 方法 模式 相 比 ， 抽 象 工 厂 模 式 中 
的 具体 工厂 不 只 是 创建 一 种 产品 ， 它 负责 创建 一 族 产品 。 抽 象 工厂 模式 定义 如 下 : 


抽象 工厂 模式 (Abstract Factory Pattern) : 提供 一 个 创建 一 系列 相关 或 相互 依赖 对 象 的 接口 ， 而 
无 须 指定 它们 具体 的 类 。 抽 象 工厂 模式 又 称 为 Kit 模 式 ， 它 是 一 种 对 象 创建 型 模式 。 


在 抽象 工厂 模式 中 ， 每 一 个 具体 工厂 都 提供 了 多 个 工厂 方法 用 于 产生 多 种 不 同类 型 的 产品 ， 
这 些 产 品 构成 了 一 个 产品 族 ， 抽 象 工厂 模式 结构 如 图 5 所 示 : 


+ CreateProductA () : AbstractProductA 
+ CreateProductB () : AbstractProductB 







ConcreteFactory1 


+ CreateProductA () : AbstractProductA 
+ CreateProductB () : AbstractProductB 


图 5 抽象 工厂 模式 结构 图 
在 抽象 工厂 模式 结构 图 中 包含 如 下 几 个 角色 : 





ConcreteFactory2 


+ CreateProductA () : AbstractProductA 
+ CreateProductB () : AbstractProductB 


@ AbstractFactory (抽象 工厂 ) : 它 声明 了 一 组 用 于 创建 一 族 产品 的 方法 ， 每 一 个 方法 对 应 一 
种 产品 。 
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@ ConcreteFactory (具体 工厂 ) : 它 实 现 了 在 抽象 工厂 中 声明 的 创建 产品 的 方法 ， 生 成 一 组 具 
体 产 品 ， 这 些 产 品 构成 了 一 个 产品 族 ， 每 一 个 产品 都 位 于 某 个 产品 等 级 结构 中 。 


e@ AbstractProduct (抽象 产品 ) : 它 为 每 种 产品 声明 接口 ， 在 抽象 产品 中 声明 了 产品 所 具有 的 
业务 方法 。 


e@ ConcreteProduct (具体 产品 ) : 它 定义 具体 工厂 生产 的 具体 产品 对 象 ， 实 现 抽 得 产品 接口 中 
声明 的 业务 方法 。 


在 抽象 工厂 中 声明 了 多 个 工厂 方法 ， 用 于 创建 不 同类 型 的 产品 ， 抽 象 工厂 可 以 是 接口 ， 也 可 
以 是 抽象 类 或 者 具体 类 ， 其 典型 代码 如 下 所 示 : 


abstract class AbstractFactory { 
public abstract AbstractProductA createProductA(); // 工 厂 方法 一 
public abstract AbstractProductB createProductB(); // 工 厂 方法 二 


具体 工厂 实现 了 抽象 工厂 ， 每 一 个 具体 的 工厂 方法 可 以 返回 一 个 特定 的 产品 对 象 ， 而 同一 个 
具体 工厂 所 创建 的 产品 对 象 构 成 了 一 个 产品 族 。 对 于 每 一 个 具体 工厂 类 ， 其 典型 代码 如 下 所 
示 : 
class ConcreteFactory1L extends AbSstractFactory { 

// 工 厂 方法 一 
public AbstractProductA createProductA() { 

return new ConcretepProductA1( ) ; 
} 


// 工 厂 方法 二 
public AbstractProductB createProductB() { 
return new ConcretepProductB1( ) ; 


与 工厂 方法 模式 一 样 ， 抽 象 工厂 模式 也 可 为 每 一 种 产品 提供 一 组 重 载 的 工厂 方法 ， 以 不 同 的 
方式 对 产品 对 象 进行 创建 。 


抽象 工厂 模式 是 否 符合 “ 开 闭 原则 ”2?2 【从 增加 新 的 产品 等 级 结构 和 增加 新 的 产品 族 两 方面 进行 
思考 。】 


71 


工厂 三 兄弟 之 抽象 工厂 模式 (四 ) 


工厂 三 兄弟 之 抽象 工厂 模式 (四 ) 
工厂 三 兄弟 之 抽象 工厂 模式 (四 ) 


4 完整 解决 方案 
Sunny 公 司 开 发 人 员 使 用 抽象 工厂 模式 来 重 构 界面 皮肤 库 的 设计 ， 其 基本 结构 如 图 6 所 示 : 


SkinFactory 


+ createButton () - Button 

+ createTextField () : TextField 

+ CreateComboBox () : ComboBox 
六 ~ 


SpringSkinFactory SummerSkinFactory 
+ createButton () :Button + createButton () : Button 
+ CreateTextField 0 : TextField + createTextField () : TextField 
+ createComboBox () : ComboBox 
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图 6 界面 皮肤 库 结构 图 


在 图 6 中 ，SkinFactory 接 口 充当 抽象 工厂 ， 其 子 类 SpringSkinFactory 和 SummerSkinFactory 充 当 
具体 工厂 ， 接 口 Button、TextField 和 ComboBox 充 当 抽 象 产 品 ， 其 子 类 SpringButton、 
SpringTextField、SpringComboBox 和 SummerButton、SummerTextField、SummerComboBox 充 
当 具 体 产 品 。 完 整 代码 如 下 所 示 : 


// 在 本 实例 中 我 们 对 代码 进行 了 大 量 简化 ， 实 际 使 用 时 ， 界 面 组 件 的 初始 化 代码 较为 复杂 ， 还 
// 按 钮 接口 : 抽象 产品 
interface Button { 
public void display(); 
} 


//Spring 按 钮 类 : 具体 产品 
class SpringButton implements Button { 
public void display() { 
System.out.println(" 显 示 浅 绿色 按钮 。")， 
} 
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//Summer 按 钮 类 : 具体 产品 
class SummerButton implements Button { 
public void display() { 
System.out.println(" 显 示 浅 蓝 色 按 钮 。")， 
} 


} 


// 文 本 框 接口 : 抽象 产品 
interface TextField { 

public void display(); 
} 


//Spring 文 本 框 类 : 具体 产品 
class SpringTextField implements TextField { 
public void display() { 
System.out.println(" 显 示 绿色 边框 文本 框 。")， 
} 


} 


//Summer 文 本 框 类 : 具体 产品 
class SummerTextField implements TextField { 
public void display() { 
System.out.println(" 显 示 蓝 色 边框 文本 框 。")， 
} 


} 


// 组 合 框 接口 : 抽象 产品 
interface ComboBox { 

public void dispJay() ; 
} 


//Spring 组 合 框 类 : 具体 产品 
class SpringComboBox implements ComboBox { 
public void display() { 
System.out.println(" 显 示 绿色 边框 组 合 框 。")， 
} 


} 


//Summer 组 合 框 类 : 具体 产品 
class SummerComboBox implements ComboBox { 
public void display() { 
System.out.println(" 显 示 蓝 色 边框 组 合 框 。")， 
} 


} 


// 界 面皮 肤 工厂 接口 : 抽象 工厂 

interface SkinFactory { 
public Button createButton(); 
public TextField createTextField( ); 
public ComboBox createComboBox(); 


} 


//Spring 皮 肤 工 厂 : 具体 工厂 
73 


工厂 三 兄弟 之 抽象 工厂 模式 (四 ) 


class SpringSkinFactory implements SkinFactory { 
public Button createButton() { 
return new SpringButton(); 
} 


public TextField createTextField() { 
return new SpringTextField(); 
} 


public ComboBox createComboBox() { 
return new SpringComboBox(); 
} 


} 


//Summer 皮 肤 工 厂 : 具体 工厂 
class SummerSkinFactory implements SkinFactory { 
public Button createButton() { 
return new SummerButton(); 
} 


public TextField createTextField() { 
return new SummerTextField(); 
} 


public ComboBox createComboBox() { 
return new SummerComboBox(); 
} 


} 


为 了 让 系统 具备 良好 的 灵活 性 和 可 扩展 性 ， 我 们 引入 了 工具 类 XMLUtil 和 配置 文件 ， 其 中 ， 
XMLUtil 类 的 代码 如 下 所 示 : 


import javax.xml.parsers.*,; 
import org.w3c.dom.*,; 

import org.xml.sax.SAXException; 
import java.io.*,; 


public class XMLUtil] { 
// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 
public static Object getBean( ) { 
try { 

// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory,newDocumentBuilder( ) ， 
Document doc; 
doc = builder.parse(new File("config.xml")); 


// 获 取 包 含 类 名 的 文本 节点 

NodeList nl = doc.getElementsByTagName("className"); 
Node classNode=nl1.item(0).getFirstChild(); 

String cName=classNode.getNodeVvalue(); 

// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
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Class c=Class.forName(cName); 
Object obj=c.newInstance( ); 
return obj; 

} 

catch(Exception e) { 
e,printStackTrace( ); 
return null; 


} 
配置 文件 config.xml 中 存储 了 具体 工厂 类 的 类 名 ， 代 码 如 下 所 示 : 


<?xml1 version="1.0"?> 
<config> 
<className>SpringSkinFactory</className> 
</config> 
编写 如 下 客户 端 测试 代码 : 
[java] view plain copy 
class Client { 
public static void main(String args[]) { 
// 使 用 抽象 层 定 义 
SkinFactory factory; 
Button bt; 
TextField tf; 
ComboBox cb 
factory = (SkinFactory)XMLUtI .getBean( ) ， 
bt = factory.createButton(); 
tf factory.createTextField( ); 
cb = factory.createComboBox( ); 
bt.display(); 
tf.display(); 
cb.display(); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 
浅 绿色 按钮 。 


绿色 边框 文本 框 。 
示 绿 色 边 框 组 合 框 。 


显示 
显示 
显 
如 果 需 要 和 更换 皮肤 ， 只 需 修 改 配置 文件 即 可 ， 在 实际 环境 中 ， 我 们 可 以 提供 可 视 化 界面 ， 例 
如 菜单 或 者 窗口 来 修改 配置 文件 ， 用 户 无 须 直接 修改 配置 文件 。 如 果 需 要 增加 新 的 皮肤 ， 只 
需 增加 一 族 新 的 具体 组 件 并 对 应 提供 一 个 新 的 具体 工厂 ， 修 改 配置 文件 即 可 使 用 新 的 皮肤 ， 
原 有 代码 无 须 修改 ， 符 合 “ 开 闭 原则 ”。 

扩展 


在 丨 实 项 目 开发 中 ， 我 们 通常 会 为 配置 文件 提供 一 个 可 视 化 的 编辑 界面 ， 类 似 Struts 框 架 
中 的 struts.xml 编 辑 器 ， 大 家 可 以 自行 开发 一 个 简单 的 图 形 化 工具 来 修改 配置 文件 ， 实 现 
监 正 的 纯 界面 操作 。 
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工厂 三 兄 第 之 抽 痊 工厂 模式 (五 ) 
工厂 三 兄弟 之 抽象 工厂 模式 〈 五 ) 


5“ 开 闭 原 则 ”的 倾斜 性 


Sunny 公 司 使 用 抽象 工厂 模式 设计 了 界面 皮肤 库 ， 该 皮肤 库 可 以 较为 方便 地 增加 新 的 皮肤 ， 但 
是 现在 遇 到 一 个 非常 严重 的 问题 : 由 于 设计 时 考虑 不 全 面 ， 总 记 为 单 选 按钮 (RadioButtom) 提 供 
不 同 皮 肤 的 风格 化 显示 ， 导 致 无 论 选择 哪 种 皮肤 ， 单 选 按钮 都 显得 那么 格格 不 入 ”。Sunny 公 
司 的 设计 人 员 决 定向 系统 中 增加 单 选 按钮 ， 但 是 发 现 原 有 系统 居然 不 能 够 在 符合 “ 开 闭 原则 ”的 
前 提 下 增加 新 的 组 件 ， 原 因 是 抽象 工厂 SkinFactory 中 根本 没有 提供 创建 单 选 按钮 的 方法 ， 如 果 
需要 增加 单 选 按钮 ， 首 先 需 要 修改 抽象 工厂 接口 SkinFactory， 在 其 中 新 增 声 明 创建 单 选 按钮 的 
方法 ， 然 后 逐个 修改 具体 工厂 类 ， 增 加 相应 方法 以 实现 在 不 同 的 皮肤 中 创建 单 选 按钮 ， 此 外 

还 需要 修改 客户 端 否则 单 选 按 钮 无 法 应 用 于 现 有 系统 。 


怎么 办 ?答案 是 抽象 工厂 模式 无 法 解决 该 问题 ， 这 也 是 抽象 工厂 模式 最 大 的 缺点 。 在 抽象 工 
厂 模式 中 ， 增 加 新 的 产品 族 很 方便 ， 但 是 增加 新 的 产品 等 级 结构 很 麻烦 ， 抽 象 工厂 模 式 的 这 
种 性 质 称 为 “< 开 闭 原则 ”的 倾斜 性 。“ 开 闭 原 则 ”要 求 系 统 对 扩展 开放 ， 对 修改 封闭 ， 通 过 扩展 达 
到 增强 其 功能 的 目的 ， 对 于 涉及 到 多 个 产品 族 与 多 个 产品 等 级 结构 的 系统 ， 其 功能 增强 包括 
两 方面 : 


(1) 增加 产品 族 : 对 于 增加 新 的 产品 族 ， 抽 象 工厂 模式 很 好 地 支持 了 “ 开 闭 原则 ”， 只 需要 增加 
具体 产品 并 对 应 增加 一 个 新 的 具体 工厂 ， 对 已 有 代码 无 须 做 任何 修改 。 


(2) 增加 新 的 产品 等 级 结构 : 对 于 增加 新 的 产品 等 级 结构 ， 需 要 修改 所 有 的 工厂 角色 ， 包 括 抽 
象 工厂 类 ， 在 所 有 的 工厂 类 中 都 需要 增加 生产 新 产品 的 方法 ， 违 背 了 “ 开 闭 原则 ”。 


正 因为 抽象 工厂 模式 存在 “ 开 闭 原则 ”的 倾斜 性 ， 它 以 一 种 倾斜 的 方式 来 满足 “ 开 闭 原则 ”， 为 增 
加 新 产品 族 提供 方便 ， 但 不 能 为 增加 新 产品 结构 提供 这 样 的 方便 ， 因 此 要 求 设 计 人 员 在 设计 
之 初 就 能 够 全 面 考虑 ， 不 会 在 设计 完成 之 后 向 系统 中 增加 新 的 产品 等 级 结构 ， 也 不 会 删除 已 
有 的 产品 等 级 结构 ， 否 则 将 会 导致 系统 出 现 较 大 的 修改 ， 为 后 续 维护 工作 带 来 诸多 麻烦 。 


6 抽象 工厂 模式 总 结 
抽象 工厂 模式 是 工厂 方法 模式 的 进一步 延伸 ， 由 于 它 提供 了 功能 更 为 强大 的 工厂 类 并 且 具 备 
较 好 的 可 扩展 性 ， 在 软件 开发 中 得 以 广泛 应 用 ， 尤 其 是 在 一 些 框架 和 API 类 库 的 设计 中 ， 例 如 
在 Java 语 言 的 AWT (抽象 窗口 工具 包 ) 中 就 使 用 了 抽象 工厂 模式 ， 它 使 用 抽象 工厂 模式 来 实 
现在 不 同 的 操作 系统 中 应 用 程序 呈现 与 所 在 操作 系统 一 致 的 外 观 界 面 。 抽 象 工 厂 模式 也 是 在 
软件 开发 中 最 常用 的 设计 模式 之 一 。 

1. 主要 优点 
抽象 工厂 模式 的 主要 优点 如 下 : 
(1) 抽象 工厂 模式 隔离 了 具体 类 的 生成 ， 使 得 客户 并 不 需要 知道 什么 被 创建 。 由 于 这 种 隔离 ， 
更 换 一 个 具体 工厂 就 变 得 相对 容易 ， 所 有 的 具体 工厂 都 实现 了 抽象 工厂 中 定义 的 那些 公共 接 
口 ， 因 此 只 需 改 变 具体 工厂 的 实例 ， 就 可 以 在 某 种 程度 上 改变 整个 软件 系统 的 行为 。 
(2) 当 一 个 产品 族 中 的 多 个 对 象 被 设计 成 一 起 工作 时 ， 它 能 够 保证 客户 端 始终 只 使 用 同一 个 产 
品 族 中 的 对 象 。 
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(3) 增加 新 的 产品 族 很 方便 ， 无 须 修改 已 有 系统 ， 符 合 “ 开 闭 原则 ”。 
1. 主要 缺点 
抽象 工厂 模式 的 主要 缺点 如 下 : 


增加 新 的 产品 等 级 结构 麻烦 ， 需 要 对 原 有 系统 进行 较 大 的 修改 ， 甚 至 需要 修改 抽象 层 代码 ， 
这 显然 会 带 来 较 大 的 不 便 ， 违 背 了 “ 开 闭 原则 ”。 


1. 适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 抽象 工厂 模式 : 


(1) 一 个 系统 不 应 当 依赖 于 产品 类 实例 如 何 被 创建 、 组 合 和 表达 的 细节 ， 这 对 于 所 有 类 型 的 工 
厂 模式 都 是 很 重要 的 ， 用 户 无 须 关心 对 象 的 创建 过 程 ， 将 对 象 的 创建 和 使 用 解 耦 。 


(2) 系统 中 有 多 于 一 个 的 产品 族 ， 而 每 次 只 使 用 其 中 某 一 产品 族 。 可 以 通过 配置 文件 等 方式 来 
使 得 用 户 可 以 动态 改变 产品 族 ， 也 可 以 很 方便 地 增加 新 的 产品 族 。 


(3) 属于 同一 个 产品 族 的 产品 将 在 一 起 使 用 ， 这 一 约束 必须 在 系统 的 设计 中 体现 出 来 。 同 一 个 
产品 族 中 的 产品 可 以 是 没有 任何 关系 的 对 象 ， 但 是 它们 都 具有 一 些 共同 的 约束 ， 如 同一 操作 
系统 下 的 按钮 和 文本 框 ， 按 钮 与 文本 框 之 间 没 有 直接 关系 ， 但 它们 都 是 属于 某 一 操作 系统 
的 ， 此 时 具有 一 个 共同 的 约束 条 件 : 操作 系统 的 类 型 。 


(4) 产品 等 级 结构 稳定 ， 设 计 完成 之 后 ， 不 会 向 系统 中 增加 新 的 产品 等 级 结构 或 者 删除 已 有 的 
产品 等 级 结构 。 


Sunny 软 件 公司 欲 推出 一 款 新 的 手机 游戏 软件 ， 该 软件 能 够 支持 Symbian、Android 和 
Windows Mobile 等 多 个 智能 手机 操作 系统 平台 ， 针 对 不 同 的 手机 操作 系统 ， 该 游戏 软件 提 
供 了 不 同 的 游戏 操作 控制 (OperationController) 类 和 游戏 界面 控制 (InterfaceController) 类 ， 

并 提供 相应 的 工厂 类 来 封装 这 些 类 的 初始 化 过 程 。 软 件 要 求 具有 较 好 的 扩展 性 以 支持 新 
的 操作 系统 平台 ， 为 了 满足 上 述 需 求 ， 试 采用 抽象 工厂 模式 对 其 进行 设计 。 
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单 例 模式 -Singleton Pattern 【学习 难度 : 雄 交 夜间 诅 ， 使 用 频率 : 次 次 克 克 六】 


。 单 例 模式 -Singleton Pattern 
o 确保 对 得 的 唯一 性 单 例 模式 (一 ) 








| 过 
o 确保 对 象 的 唯一 性 一 一 单 例 模式 (三 
o 确保 对 象 的 唯一 性 一 一 单 例 模 式 (四 ) 
o 确保 对 象 的 唯一 性 一 一 单 例 模式 (五 ) 
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确保 对 象 的 唯一 性 一 单 例 模式 (一 ) 
确保 对 象 的 唯一 性 一 单 例 模式 (一 ) 


3.1 单 例 模式 的 动机 


对 于 一 个 软件 系统 的 某 些 类 而 言 ， 我 们 无 须 创 建 多 个 实例 。 举 个 大 家 都 熟知 的 例子 
Windows 任 务 管理 器 ， 如 图 3-1 所 示 ， 我 们 可 以 做 一 个 这 样 的 尝试 ， 在 Windows 的 “任务 栏 ”的 右 
键 弹出 菜单 上 多 次 点 击 “ 启 动 任 务 管理 器 ”， 看 能 否 打开 多 个 任务 管理 器 窗口 ? 如 果 你 的 桌面 出 
现 多 个 任务 管理 器 ， 我 请 你 吃饭 ， 微 笑 ( 注 : 电脑 中 毒 或 私自 修改 Windows 内 核 者 除外 ) 。 通 
常情 况 下 ， 无 论 我 们 启动 任务 管理 多 少 次 ，Windows 系 统 始终 只 能 弹出 一 个 任务 管理 器 窗口 ， 
也 就 是 说 在 一 个 Windows 系 统 中 ， 任 务 管理 器 存在 唯一 性 。 为 什么 要 这 样 设计 呢 ? 我 们 可 以 从 
以 下 两 个 方面 来 分 析 : 其 一 ， 如 果 能 弹出 多 个 窗口 ， 且 这 些 窗口 的 内 容 完 全 一 致 ， 全 部 是 重 
复 对 象 ， 这 势必 会 浪费 系统 资源 ， 任 务 管理 器 需要 获取 系统 运行 时 的 诸多 信息 ， 这 些 信息 的 
获取 需要 消耗 一 定 的 系统 资源 ， 包 括 CPU 资 源 及 内 存 资 源 等 ， 浪 费 是 可 耻 的 ， 而 且 根 本 没有 
必要 显示 多 个 内 容 完 全 相同 的 窗口 ; 其 二 ， 如 果 弹 出 的 多 个 窗口 内 容 不 一 致 ， 问 题 就 更 加 严 
重 了 ， 这 意味 着 在 某 一 瞬间 系统 资源 使 用 情况 和 进程 ~、 服务 等 信息 存在 多 个 状态 ， 例 如 任务 
管理 器 窗口 A 显示 “CPU 使 用 率 ” 为 10%， 窗 口 B 显 示 “CPU 使 用 率 ” 为 15%， 到 底 哪个 才 是 丨 实 的 
呢 ? 这 纯 属 “调戏 ”用户 ， 偷 笑 ， 给 用 户 带 来 误解 ， 更 不 可 取 。 由 此 可 见 ， 确 保 Windows 任 务 管 
理 器 在 系统 中 有 且 仅 有 一 个 非常 重要 。 


而 








' 昌 Windows 任务 管理 扣 -二 -G- 区 引 
文 忻 (F) ”和 运 项 (OQ) 查看 (V) 帮助 (H) 


应 用 程序 | 进程 | 服务 | 性 能 | 联网 
CPV 侠 用 这 CPU 使 用 记录 


| 用户 
内 存 物理 内 存 使 用 记录 





物理 内 存 1B) 系统 
总 救 1971 句柄 数 28335 
已 组 存 694 线程 到 1039 
司 1233 进程 到 65 
空 用 579 ”开机 时 间 0:12:53;26 
实心 内 存 Qn5) 提交 (NB) 1334 / 3943 
分 页 数 208 a s 
未 分 页 53 资源 此 祝 器 全). 

进程 数 : 65 CPU 使 用 率 : 10% 物理 内 存 : 37% 





图 3-1 Windows 任 务 管理 器 

回 到 实际 开发 中 ， 我 们 也 经 常 遇 到 类 似 的 情况 ， 为 了 节约 系统 资源 ， 有 时 需要 确保 系统 中 某 
个 类 只 有 唯一 一 个 实例 ， 当 这 个 唯一 实例 创建 成 功 之 后 ， 我 们 无 法 再 创建 一 个 同类 型 的 其 他 
对 象 ， 所 有 的 操作 都 只 能 基于 这 个 唯一 实例 。 为 了 确保 对 象 的 唯一 性 ， 我 们 可 以 通过 单 例 模 
式 来 实现 ， 这 就 是 单 例 模式 的 动机 所 在 。 

3.2 单 例 模式 概述 


下 面 我 们 来 模拟 实现 Windows 任 务 管理 器 ， 假 设 任务 管理 器 的 类 名 为 TaskManager， 在 
TaskManager 类 中 包含 了 大 量 的 成 员 方 法 ， 例 如 构造 函数 TaskManager() ， 显 示 进程 的 方法 
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displayProcesses()， 显 示 服 务 的 方法 displayServices() 等 ， 该 类 的 示意 代码 如 下 : 
class TaskManager 
public TaskManager() {i} // 初 始 化 窗口 


public void displayProcesses()  {.….} // 显 示 进 程 
public void displayServices() {..} // 显 示 服 务 


为 了 实现 Windows 任 务 管理 器 的 唯一 性 ， 我 们 通过 如 下 三 步 来 对 该 类 进行 重 构 : 


(1) 由 于 每 次 使 用 new 关 键 字 来 实例 化 TaskManager 类 时 都 将 产生 一 个 新 对 象 ， 为 了 确保 
TaskManager 实 例 的 唯一 性 ， 我 们 需要 禁止 类 的 外 部 直接 使 用 new 来 创建 对 象 ， 因 此 需要 将 
TaskManager 的 构造 下 数 的 可 见 性 改 为 private， 如 下 代码 所 示 : 


private TaskManager() {£.....} 


(2) 将 构造 函数 改 为 private 修 饰 后 该 如 何 创建 对 象 呢 ? 不 要 着 急 ， 虽 然 类 的 外 部 无 法 再 使 用 new 
来 创建 对 象 ， 但 是 在 TaskManager 的 内 部 还 是 可 以 创建 的 ， 可 见 性 只 对 类 外 有 效 。 因 此 ， 我 们 
可 以 在 TaskManager 中 创建 并 保存 这 个 唯一 实例 。 为 了 让 外 界 可 以 访问 这 个 唯一 实例 ， 需 要 在 
TaskManager 中 定义 一 个 静态 的 TaskManager 类 型 的 私有 成 员 变 量 ， 如 下 代码 所 示 : 


private static TaskManager tm = nu]1， 

(3) 为 了 保证 成 员 变 量 的 封装 性 ， 我 们 将 TaskManager 类 型 的 tm 对 象 的 可 见 性 设置 为 private， 但 
外 办 该 如 何 使 用 该 成 员 变 量 并 何 时 实例 化 该 成 员 变量 呢 ? 答案 是 增加 一 个 公有 的 静态 方法 ， 
如 下 代码 所 示 : 


public static TaskManager getInstance() 


if (tm == null) 
{ 


} 


return tm， 


tm = new TaskManager(); 


} 

在 getInstance() 方 法 中 首先 判断 tm 对 象 是 否 存 在 ， 如 果 不 存在 ( 即 tm == null) ， 则 使 用 new 关 
键 字 创建 一 个 新 的 TaskManager 类 型 的 tm 对 象 ， 再 返回 新 创建 的 tm 对象 ; 否则 直接 返回 已 有 的 
tm 对 和 象 。 

需要 注意 的 是 getInstance() 方 法 的 修饰 符 ， 首 先 它 应 该 是 一 个 public 方 法 ， 以 便 供 外 界 其 他 对 象 
使 用 ， 其 次 它 使 用 了 static 关 键 字 ， 即 它 是 一 个 静态 方法 ， 在 类 外 可 以 直接 通过 类 名 来 访问 ， 
而 无 须 创 建 TasskManager 对 象 ， 事 实 上 在 类 外 也 无 法 创建 TaskManager 对 象 ， 因 为 构造 函数 是 私 
有 的 。 

思考 

为 什么 要 将 成 员 变 量 tm 定 义 为 静态 变量 ? 

通过 以 上 三 个 步 又， 我 们 完成 了 一 个 最 简单 的 单 例 类 的 设计 ， 其 完整 代码 如 下 : 


class TaskManager 


{ 
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private Static TaskManager tm = nu]1， 

private TaskManager() {.….} // 初 始 化 窗口 

public void displayProcesses() {....} // 显 示 进 程 
public void displayServices() {...} // 显 示 服 务 
public static TaskManager getInstance() 


{ 
If (tm == null) 
{ 
tm = new TaskManager(); 
} 


return tm， 


在 类 外 我 们 无 法 直接 创建 新 的 TaskManager 对 象 ， 但 可 以 通过 代码 TaskManager.getInstance() 来 
访问 实例 对 象 ， 第 一 次 调用 getInstance() 方 法 时 将 创建 唯一 实例 ， 再 次 调用 时 将 返回 第 一 次 创 
建 的 实例 ， 从 而 确保 实例 对 象 的 唯一 性 。 


上 述 代码 也 是 单 例 模 式 的 一 种 最 典型 实现 方式 ， 有 了 以 上 基础 ， 理 解 单 例 模式 的 定义 和 结构 
就 非常 容易 了 。 单 例 模 式 定义 如 下 : 单 例 模式 (Singleton Pattern) : 确保 茶 一 个 类 只 有 一 个 实 
例 ， 而 且 自 行 实例 化 并 向 整个 系统 提供 这 个 实例 ， 这 个 类 称 为 单 例 类 ， 它 提供 全 局 访问 的 方 
法 。 单 例 模 式 是 一 种 对 象 创建 型 模式 。 


单 例 模式 有 三 个 要 点 : 一 是 某 个 类 只 能 有 一 个 实例 ; 二 是 它 必须 自行 创建 这 个 实例 ; 三 是 它 
必须 自行 向 整个 系统 提供 这 个 实例 。 


单 例 模 式 是 结构 最 简单 的 设计 模式 一 ， 在 它 的 核心 结构 中 只 包含 一 个 被 称 为 单 例 类 的 特殊 
类 。 单 例 模 式 结构 如 图 3-2 所 示 : 







Singleton 
-instance : Singleton 


- Singleton () 
.+ Getlnstance () : Singleton 





> 


if(instance==null) 
instance=new Singleton(): 


retum instance: 





图 3-2 单 例 模式 结构 图 。 


单 例 模 式 结构 图 中 只 包含 一 个 单 例 角 色 : 

e@ Singleton ( 单 例 ) : 在 单 例 类 的 内 部 实现 只 生成 一 个 实例 ， 同 时 它 提供 一 个 静态 的 
getInstance() 工 厂 方法 ， 让 客户 可 以 访问 它 的 唯一 实例 ; 为 了 防止 在 外 部 对 其 实例 化 ， 将 其 构 
造 泡 数 设 计 为 私有 ; 在 单 例 类 内 部 定义 了 一 个 Singleton 类 型 的 静态 对 象 ， 作 为 外 部 共享 的 唯一 
实例 。 
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3.3 负载 均衡 器 的 设计 与 实现 


Sunny 软 件 公司 承接 了 一 个 服务 器 负载 均衡 (Load Balance) 软 件 的 开发 工作 ， 该 软件 运行 在 一 台 
负载 均衡 服务 器 上 ， 可 以 将 并 发 访问 和 数据 流量 分 发 到 服务 器 集群 中 的 多 台 设 备 上 进行 并 发 
处 理 ， 提 高 系统 的 整体 处 理 能 力 ， 缩 短 响 应 时 间 。 由 于 集群 中 的 服务 器 需要 动态 删 减 ， 且 客 
户 端 请 求 需要 统一 分 发 ， 因 此 需要 确保 负载 均衡 器 的 唯一 性 ， 只 能 有 一 个 负载 均衡 器 来 负责 
服务 器 的 管理 和 请 求 的 分 发 ， 否 则 将 会 带 来 服务 器 状态 的 不 一 致 以 及 请 求 分 配 冲 突 等 问题 。 
如 何 确保 负载 均衡 器 的 唯一 性 是 该 软件 成 功 的 关键 。 


Sunny 公 司 开发 人 员 通 过 分 析 和 权衡 ， 决 定 使 用 单 例 模 式 来 设计 该 负载 均衡 器 ， 结 构图 如 图 3-3 
所 示 : 






LoadBalancer 


- instance :LoadBalancer = null 

- ServerList : List = null 

- LoadBalancer () 

+ getLoadBalancer () :LoadBalancer 


+ addServer (String server) : Void 
+ removeServer (String server) : void 
+ getServer () : String 


图 3-3 服务 器 负载 均衡 器 结构 图 。 


在 图 3-3 中 ， 将 负载 均衡 器 LoadBalancer 设 计 为 单 例 类 ， 其 中 包含 一 个 存储 服务 器 信息 的 集合 
serverList ， 每 次 在 serverList 中 随机 选择 一 台 服 务 器 来 响应 客户 端的 请 求 ， 实 现代 码 如 下 所 
示 : 


import java.util.*,; 


// 负 载 均衡 器 LoadBalancer : 单 例 类 ， 盖 实 环境 下 该 类 将 非常 复杂 ， 包 括 大 量 初始 化 的 工人 
class LoadBalancer { 

// 私 有 静态 成 员 变 量 ， 存 储 唯一 实例 

private static LoadBalancer instance = null; 

// 服 务 器 集合 

private List serverList = null,; 


// 私 有 构造 函数 
private LoadBalancer() { 
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} 


serverList = new ArrayList(); 


} 


// 公 有 静态 成 员 方 法 ， 返 回 唯一 实例 
public static LoadBalancer getLoadBalancer() { 
If (instance == null) { 
instance = new LoadBalancer(); 


} 

return instance,; 
} 
// 增 加 服务 器 


public void addServer(String server) { 
serverList.add(server); 
} 


// 删 除 服务 器 

public void removeServer(String server) { 
serverList.remove(server); 

} 


// 使 用 Random 类 随机 获取 服务 器 

public String getServer() { 
Random random = new Random(); 
int i = random.nextInt(serverList.sizel()); 
return (String)serverList.get(i); 


编写 如 下 客户 端 测试 代码 : 


class Client { 
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public static void main(String args[]) { 
// 创 建 四 个 LoadBalancer 对 得 
LoadBalancer balanceri1,balancer2,balancer3,balancer4; 
balancer1 = LoadBalancer .getLoadBalancer( ); 


balancer2 = LoadBalancer .getLoadBalancer(); 
balancer3 = LoadBalancer .getLoadBalancer( ); 
balancer4 = LoadBalancer .getLoadBalancer( ); 


// 判 断 服 务 器 负载 均衡 器 是 否 相同 

if (balancer1 == balancer2 && balancer2 == balancer3 && bala 
System.out.println(" 服 务 器 负载 均衡 器 具有 唯一 性 ! ")， 

} 


// 增 加 服务 器 

balanceri.addServer("Server 1' 
balanceri1.addServer("Server 2' 
balanceri.addServer("Server 3 
balanceri.addServer("Server 4' 


了 
了 


了 


') 
» 
) 
3:) 


了 


// 模 拟 客户 端 请 求 的 分 发 
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for (int i = 0; i < 10; i++) { 
String Server = balanceri1.getServer(); 
System.out .println(" 分 发 请 求 至 服务 器 : " + server); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 
器 负 载 均衡 器 具 A 有 唯一 性 | 


分 发 请 求 至 服务 器 : Server 1 
分 发 请 求 至 服务 器 : Server 3 
分 发 请 求 至 服务 器 : Server 4 
分 发 请 求 至 服务 器 : Server 2 
分 发 请 求 至 服务 器 : Server 3 
分 发 请 求 至 服务 器 : Server 2 
分 发 请 求 至 服务 器 : Server 3 
分 发 请 求 至 服务 器 : Server 4 
分 发 请 求 至 服务 器 : Server 4 
分 发 请 求 至 服务 器 : Server 1 


虽然 创建 了 四 个 LoadBalancer 对 和 象 ， 但 是 它们 实际 上 是 同一 个 对 象 ， 因 此 ， 通 过 使 用 单 例 模式 
可 以 确保 LoadBalancer 对 象 的 唯一 性 。 
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确保 对 象 的 唯一 性 一 单 例 模式 (三 ) 
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3.4 钱 汉 式 单 例 与 懒汉 式 单 例 的 讨论 


Sunny 公 司 开发 人 员 使 用 单 例 模 式 实现 了 负载 均衡 器 的 设计 ， 但 是 在 实际 使 用 中 出 现 了 一 个 非 
常 严重 的 问题 ， 当 负载 均衡 器 在 启动 过 程 中 用 户 再 次 启动 该 负载 均衡 器 时 ， 系 统 无 任何 异 
常 ， 但 当 客户 端 提交 请 求 时 出 现 请 求 分 发 失败 ， 通 过 仔细 分 析 发 现 原来 系统 中 还 是 存在 多 个 
负载 均衡 器 对 象 ， 导 致 分 发 时 目标 服务 器 不 一 致 ， 从 而 产生 冲突 。 为 什么 会 这 样 呢 ? Sunny 公 
司 开发 人 员 百 思 不 得 其 解 。 


现在 我 们 对 负载 均衡 器 的 实现 代码 进行 再 次 分 析 ， 当 第 一 次 调用 getLoadBalancer() 方 法 创建 并 
启动 负载 均衡 器 时 ，instance 对 象 为 null 值 ， 因 此 系统 将 执行 代码 instance= new 
LoadBalancer()， 在 此 过 程 中 ， 由 于 要 对 LoadBalancer 进 行 大 量 初始 化 工作 ， 需 要 一 段 时 间 来 创 
建 LoadBalancer 对 象 。 而 在 此 时 ， 如 果 再 一 次 调用 getLoadBalancer() 方 法 (通常 发 生 在 多 线程 
环境 中 ) ， 由 于 instance 尚 未 创建 成 功 ， 仍 为 null 值 ， 判 断 条 件 (instance== null) 为 引 值 ， 因 此 代 
码 instance= new LoadBalancer() 将 再 次 执行 ， 导 致 最 终 创建 了 多 个 instance 对 和 象 ， 这 违背 了 单 例 
模式 的 初衷 ， 也 导致 系统 运行 发 生 错 误 。 


如 何 解 决 该 问题 ?了 我 们 至 少 有 两 种 解决 方案 ， 在 正式 介绍 这 两 种 解决 方案 之 前 ， 先 介绍 一 下 
单 例 类 的 两 种 不 同 实现 方式 ， 饿 汉 式 单 例 类 和 懒汉 式 单 例 类 。 


1. 饿 汉 式 单 例 类 
饿 汉 式 单 例 类 是 实现 起 来 最 简单 的 单 例 类 ， 饭 汉 式 单 例 类 结构 图 如 图 3-4 所 示 : 







EagerSingleton 





re “+- instance : EagerSingleton = new EagerSingleton() = 
- EagerSingleton () | 

+ getinstance () : EagerSingleton | 

| | 

| BeSi5 > 


图 3-4 饼 汉 式 单 例 结 构图 ， 
从 图 3-4 中 可 以 看 出 ， 由 于 在 定义 静态 变量 的 时 候 实 例 化 单 例 类 ， 因 此 在 类 加 载 的 时 候 就 已 经 
创建 了 单 例 对 象 ， 代 码 如 下 所 示 : 


class EagerSingleton { 
private static final EagerSingleton instance = new EagerSingleto 
private EagerSingleton() { } 


public static EagerSingleton getInstance() { 
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return Instance 


} 

当 类 被 加 载 时 ， 静 态 变量 instance 会 被 初始 化 ， 此 时 类 的 私有 构造 函数 会 被 调用 ， 单 例 类 的 唯 
一 实例 将 被 创建 。 如 果 使 用 饿 汉 式 单 例 来 实现 负载 均衡 器 LoadBalancer 类 的 设计 ， 则 不 会 出 现 
创建 多 个 单 例 对 银 的 情况 ， 可 确保 单 例 对 象 的 唯一 性 。 

2. 懒 汉 式 单 例 类 与 线程 锁定 


除了 饿 汉 式 单 例 ， 还 有 一 种 经 典 的 懒汉 式 单 例 ， 也 就 是 前 面 的 负载 均衡 器 LoadBalancer 类 的 实 
现 方 式 。 懒 汉 式 单 例 类 结构 图 如 图 3-5 所 示 : 













LazySingleton 





-十 -instance : LazySingleton =null 后 ] 
Instance 

- LazySingleton () | 

‘|* getinstance () :LazySingleton | 

| | 

| | 


if(instance==nuIl) 
instance=new LazySingleton!(); 


return instance: 





3-5 懒汉 式 单 例 结构 图 。 


从 图 3-5 中 可 以 看 出 ， 懒 汉 式 单 例 在 第 一 次 调用 getInstance() 方 法 时 实例 化 ， 在 类 加 载 时 并 不 自 
行 实 例 化 ， 这 种 技术 又 称 为 延迟 加 载 (Lazy Load) 技 术 ， 即 需要 的 时 候 再 加 载 实 例 ， 为 了 避免 
多 个 线程 同时 调用 getInstance() 方 法 ， 我 们 可 以 使 用 关键 字 synchronized， 代 码 如 下 所 示 : 


class LazySingleton { 
private static LazySingleton instance = null; 


private LazySingleton() { } 


synchronized public static LazySingleton getInstance() { 
if (instance == null) { 
instance = new LazySingleton(); 
} 


return instance; 


} 


该 懒汉 式 单 例 类 在 getInstance() 方 法 前 面 增加 了 关键 字 synchronized 进 行 线程 锁 ， 以 处 理 多 个 线 
程 同时 访问 的 问题 。 但 是 ， 上 述 代码 虽然 解决 了 线程 安全 问题 ， 但 是 每 次 调用 getInstance() 时 
都 需要 进行 线程 锁定 判断 ， 在 多 线程 高 并 发 访问 环境 中 ， 将 会 导致 系统 性 能 大 大 降低 。 如 何 
既 解 决 线程 安全 问题 又 不 影响 系统 性 能 呢 ? 我 们 继续 对 懒汉 式 单 例 进 行 改进 。 事 实 上 ， 我 们 
无 须 对 整个 getInstance() 方 法 进行 锁定 ， 只 需 对 其 中 的 代码 “instance = new LazySingleton();” 进 
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行 锁定 即 可 。 因 此 getInstance() 方 法 可 以 进行 如 下 改进 : 


public static LazySingleton getInstance() { 
if (instance == null) { 
synchronized (LazySingleton.class) { 
instance = new LazySingleton(); 
} 


} 


return instance; 


} 


问题 貌似 得 以 解决 ， 事 实 并 非 如 此 。 如 果 使 用 以 上 代码 来 实现 单 例 ， 还 是 会 存在 单 例 对 象 不 
唯一 。 原 因 如 下 : 


假如 在 某 一 瞬间 线程 A 和 线程 B 都 在 调用 getInstance() 方 法 ， 此 时 instance 对 象 为 null 值 ， 均 能 通 
过 instance == null 的 判断 。 由 于 实现 了 synchronized 加 锁 机 制 ， 线 程 A 进 入 synchronized 锁 定 的 代 
码 中 执行 实例 创建 代码 ， 线 程 B 处 于 排队 等 待 状态 ， 必 须 等 待 线程 A 执 行 完毕 后 才 可 以 进入 
synchronized 锁 定 代码 。 但 当 A 执 行 完 毕 时 ， 线 程 B 并 不 知道 实例 已 经 创建 ， 将 继续 创建 新 的 实 
例 ， 导 致 产生 多 个 单 例 对 象 ， 违 背 单 例 模 式 的 设计 思想 ， 因 此 需要 进行 进一步 改进 ， 在 
synchronized 中 再 进行 一 次 (instance == null) 判 断 ， 这 种 方式 称 为 双重 检查 锁定 (Double-Check 
Locking)。 使 用 双重 检查 锁定 实现 的 懒汉 式 单 例 类 完整 代码 如 下 所 示 : 


class LazySingleton { 
private volatile static LazySingleton instance = null; 


private LazySingleton() { } 


public static LazySingleton getInstance() { 
// 第 一 重 判 断 
if (instance == null) { 
// 锁 定 代 码 块 
synchronized (LazySingleton.class) { 
// 第 二 重 判 断 
if (instance == null) { 
instance = new LazySingleton(); // 创 建 单 例 实例 
} 


} 
} 


return instance; 


} 


需要 注意 的 是 ， 如 果 使 用 双重 检查 锁定 来 实现 懒汉 式 单 例 类 ， 需 要 在 静态 成 员 变 量 instance 之 
前 增加 修饰 符 volatile， 被 volatile 修 饰 的 成 员 变 量 可 以 确保 多 个 线程 都 能 够 正确 处 理 ， 且 该 代 
码 只 能 在 JDK 1.5 及 以 上 版 本 中 才能 正确 执行 。 由 于 volatile 关 键 字 会 屏蔽 Java 庶 拟 机 所 做 的 一 
些 代 码 优 化 ， 可 能 会 导致 系统 运行 效率 降低 ， 因 此 即使 使 用 双重 检查 锁定 来 实现 单 例 模式 也 
不 是 一 种 完美 的 实现 方式 。 


扩展 


IBM 公 司 高 级 软件 工程 师 Peter Haggar 2004 年 在 IBM developerWorks 上 发 表 了 一 篇 名 为 《双重 
检查 锁定 及 单 例 模式 一 全 面 理解 这 一 失效 的 编程 习 语 》 的 文章 ， 对 JDK 1.5 之 前 的 双重 检查 
锁定 及 单 例 模 式 进行 了 全 面 分 析 和 阅 述 ， 参 考 链 

接 : http:/www.ibm.com/developerworks/cn/java/j-dcl.html 
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3. 钱 汉 式 单 例 类 与 懒汉 式 单 例 类 比较 


饿 汉 式 单 例 类 在 类 被 加 载 时 就 将 自己 实例 化 ， 它 的 优点 在 于 无 须 考虑 多 线程 访问 问题 ， 可 以 
确保 实例 的 唯一 性 ; 从 调用 速度 和 反应 时 间 角 度 来 讲 ， 由 于 单 例 对 象 一 开始 就 得 以 创建 ， 
此 要 优 于 懒汉 式 单 例 。 但 是 无 论 系统 在 运行 时 是 否 需要 使 用 该 单 例 对 象 ， 由 于 在 类 加 载 时 该 
对 象 就 需要 创建 ， 因 此 从 资源 利用 效率 角度 来 讲 ， 馈 汉 式 单 例 不 及 懒汉 式 单 例 ， 而 且 在 系统 
加 载 时 由 于 需要 创建 钱 汉 式 单 例 对 象 ， 加 载 时间 可 能 会 比较 长 。 


懒汉 式 单 例 类 在 第 一 次 使 用 时 创建 ， 无 须 一 直 占 用 系统 资源 ， 实 现 了 延迟 加 载 ， 但 是 必须 处 
理 好 多 个 线程 同时 访问 的 问题 ， 特 别 是 当 单 例 类 作为 资源 控制 器 ， 在 实例 化 时 必然 涉及 资源 
初始 化 ， 而 资源 初始 化 很 有 可 能 耗费 大 量 时 间 ， 这 意味 着 出 现 多 线程 同时 首次 引用 此 类 的 机 
率 变 得 较 大 ， 需 要 通过 双重 检查 锁定 等 机 制 进 行 控制 ， 这 将 导致 系统 性 能 受到 一 定 影响 。 
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3.5 一 种 更 好 的 单 例 实 现 方 法 


饿 汉 式 单 例 类 不 能 实现 延迟 加 载 ， 不 管 将 来 用 不 用 始终 占据 内 存 ; 懒汉 式 单 例 类 线程 安全 控 
制 烦 琐 ， 而 且 性 能 受 影响 。 可 见 ， 无 论 是 饿 汉 式 单 例 还 是 懒汉 式 单 例 都 存在 这 样 那样 的 问 
题 ， 有 没有 一 种 方法 ， 能 够 将 两 种 单 例 的 缺点 都 克服 ， 而 将 两 者 的 优点 合 二 为 一 呢 ? 答案 
是 : Yes ! 下 面 我 们 来 学 习 这 种 更 好 的 被 称 之 为 Initialization Demand Holder (IoDH) 的 技术 。 


在 IoDH 中 ， 我 们 在 单 例 类 中 增加 一 个 静态 (static) 内 部 类 ， 在 该 内 部 类 中 创建 单 例 对 象 ， 再 将 
该 单 例 对 象 通过 getInstance() 方 法 返回 给 外 部 使 用 ， 实 现代 码 如 下 所 示 : 


//Initialization on Demand Holder 
class Singleton { 
private Singleton() { 


} 


private static class HolderClass { 
private final static Singleton instance = new Singleton( 


} 


public static Singleton getInstance() { 
return HolderClass.instance; 


} 


public static void main(String args[]) { 
Singleton si, s2; 
si1 = Singleton.getIinstance(); 
S2 = Singleton.getIinstance(); 
System,out,println(S1==S2 ) ; 


} 


编译 并 运行 上 述 代码 ， 运 行 结 果 为 : true， 即 创建 的 单 例 对 象 s1 和 s2 为 同一 对 象 。 由 于 静态 单 
例 对 象 没有 作为 Singleton 的 成 员 变 量 直接 实例 化 ， 因 此 类 加 载 时 不 会 实例 化 Singleton， 第 一 次 
调用 getInstance() 时 将 加 载 内 部 类 HolderClass， 在 该 内 部 类 中 定义 了 一 个 static 类 型 的 变量 
instance， 此 时 会 首先 初始 化 这 个 成 员 变 量 ， 由 Java 虚 拟 机 来 保证 其 线程 安全 性 ， 确 保 该 成 员 
变量 只 能 初始 化 一 次 。 由 于 getInstance() 方 法 没有 任何 线程 锁定 ， 因 此 其 性 能 不 会 造成 任何 影 
响 。 


通过 使 用 IoDH， 我 们 既 可 以 实现 延迟 加 载 ， 又 可 以 保证 线程 安全 ， 不 影响 系统 性 能 ， 不 失 为 
一 种 最 好 的 Java 语 言 单 例 模式 实现 方式 (其 缺点 是 与 编程 语言 本 身 的 特性 相关 ， 很 多 面向 对 象 
语言 不 支持 IoODH) 。 

练习 


分 别 使 用 铁汉 式 单 例 、 带 双重 检查 锁定 机 制 的 懒汉 式 单 例 以 及 IoDH 技 术 实现 负载 均衡 器 


LoadBalancer ° 
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至 此 ， 三 种 单 例 类 的 实现 方式 我 们 均 已 学 习 完毕 ， 它 们 分 别 是 饿 汉 式 单 例 、 懒 汉 式 单 例 以 及 
IoDH 。 
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3.6 单 例 模式 总 结 


单 例 模式 作为 一 种 目标 明确 、 结 构 简 单 、 理 解 容易 的 设计 模式 ， 在 软件 开发 中 使 用 频率 相当 
高 ， 在 很 多 应 用 软件 和 框架 中 都 得 以 广泛 应 用 。 


1. 主 要 优点 
单 例 模式 的 主要 优点 如 下 : 


(1) 单 例 模 式 提供 了 对 唯一 实例 的 受 控 访问 。 因 为 单 例 类 封装 了 它 的 唯一 实例 ， 所 以 它 可 以 严 
格 控制 客户 怎样 以 及 何 时 访问 它 。 


(2) 由 于 在 系统 内 存 中 只 存在 一 个 对 象 ， 因 此 可 以 节约 系统 资源 ， 对 于 一 些 需要 频繁 创建 和 销 
角 的 对 象 单 例 模式 无 疑 可 以 提高 系统 的 性 能 。 


(3) 允许 可 变数 目的 实例 。 基 于 单 例 模 式 我 们 可 以 进行 扩展 ， 使 用 与 单 例 控制 相似 的 方法 来 获 
得 指定 个 数 的 对 象 实例 ， 既 节省 系统 资源 ， 又 解决 了 单 例 单 例 对 象 共 享 过 多 有 损 性 能 的 问 
题 。 

2. 主 要 缺点 

单 例 模式 的 主要 缺点 如 下 : 

(1) 由 于 单 例 模 式 中 没有 抽象 层 ， 因 此 单 例 类 的 扩展 有 很 大 的 困难 。 

(2) 单 例 类 的 职责 过 重 ， 在 一 定 程度 上 违背 了 “单一 职责 原则 ”。 因 为 单 例 类 既 充 当 了 工厂 角 
色 ， 提 供 了 工厂 方法 ， 同 时 又 充当 了 产品 角色 ， 包 含 一 些 业务 方法 ， 将 产品 的 创建 和 产品 的 
本 身 的 功能 融合 到 一 起 。 

(3) 现在 很 多 面向 对 象 语言 (如 Java、C 灿 的 运行 环境 都 提供 了 自动 垃圾 回收 的 技术 ， 因 此 ， 如 
果实 例 化 的 共享 对 象 长 时 间 不 被 利用 ， 系 统 会 认为 它 是 垃圾 ， 会 自动 销毁 并 回收 资源 ， 下 次 
利用 时 又 将 重新 实例 化 ， 这 将 导致 共享 的 单 例 对 象 状态 的 丢失 。 

3. 适 用 场景 

在 以 下 情况 下 可 以 考虑 使 用 单 例 模式 : 


(1) 系统 只 需要 一 个 实例 对 象 ， 如 系统 要 求 提供 一 个 唯一 的 序列 号 生成 器 或 资源 管理 器 ， 或 者 
需要 考虑 资源 消耗 太 大 而 只 允许 创建 一 个 对 象 。 


(2) 客户 调用 类 的 单个 实例 只 允许 使 用 一 个 公共 访问 点 ， 除 了 该 公共 访问 点 ， 不 能 通过 其 他 途 
径 访问 该 实例 。 


思 考 
如 何 对 单 例 模式 进行 改造 ， 使 得 系统 中 某 个 类 的 对 象 可 以 存在 有 限 多 个 ， 例 如 两 例 或 三 例 ? 
【 注 ; 改造 之 后 的 类 可 称 之 为 多 例 类 。]】 
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原型 模式 -Prototype Pattern 【学 习 难 度 : 龙 妈 友 交 夜 ， 使 用 频率 : 次 次 六 交 次 】 


e 原型 模式 -Prototype Pattern 
o 对 象 的 克隆 原型 模式 (一 ) 
o 对 象 的 克隆 原型 模式 (二 ) 
o 对 象 的 克隆 原型 模式 (三 ) 
o 对 象 的 克隆 原型 模式 (四) 
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张纪中 版 《西游 记 》 以 出 乎 意料 的 造型 和 雷 人 的 台词 遭 到 广大 观众 朋友 的 热 议 ， 我 们 在 此 对 
该 话题 不 作 过 多 讨论 。 但 无 论 是 哪个 版 本 的 《西游 记 》， 和 孙悟空 都 是 其 中 的 一 号 雄性 主角 ， 
关于 他 (或 它 ) 拔 毛 变 小 猴 的 故事 几乎 人 人 涡 知 ， 和 孙悟空 可 以 用 猴 毛 根据 自己 的 形象 ， 复 制 
(又 称 “ 克 隆 ” 或 “拷贝 ") 出 很 多 跟 自 己 长 得 一 模 一 样 的 “ 身 外 身 ” 来 。 在 设计 模式 中 也 存在 一 个 
类 似 的 模式 ， 可 以 通过 一 个 原型 对 象 克隆 出 多 个 一 模 一 样 的 对 象 ， 该 模式 称 之 为 原型 模式 。 


7.1 大 同 小 异 的 工作 周报 


Sunny 软 件 公 司 一 直 使 用 自行 开发 的 一 套 OA (Office Automatic， 办 公 自 动 化 ) 系 统 进行 日 常 工作 
办 理 ， 但 在 使 用 过 程 中 ， 越 来 越 多 的 人 对 工作 周报 的 创建 和 编写 模块 产生 了 抱 奶 。 追 其 原 

因 ，Sunny 软 件 公司 的 OA 管理 员 发 现 ， 由 于 某 些 岗位 每 周 工作 存在 重复 性 ， 工 作 周 报 内 容 都 
大 同 小 异 ， 如 图 7-1 工 作 周 报 示意 图 。 这 些 周报 只 有 一 些小 地 方 存在 差异 ， 但 是 现行 系统 每 周 
默认 创建 的 周报 都 是 空白 报表 ， 用 户 只 能 通过 重新 输入 或 不 断 复制 粘贴 来 填写 重复 的 周报 内 
容 ， 极 大 降低 了 工作 效率 ， 浪 费 宝贵 的 时 间 。 如 何 快速 创建 相同 或 者 相似 的 工作 周报 ， 成 为 
Sunny 公 司 OA 开 发 人 员 面 临 的 一 个 新 闻 题 。 

















= 可 本 十 
工作 周报 工作 周报 
姓名 : 小 龙 女 部 门 : 研发 一 部 职位 : 经 理 助理 第 16 周 姓名 : 小 龙 女 部 门 : 研发 一 部 职位 : 经 理 助理 第 17 周 
周一 : 整理 上 周 各 项 目 进展 报告 ， 向 经 理 汇报 汇总 结果 周一 : 整理 上 周 各 项 目 进 展 报告 ， 向 经 理 汇报 汇总 结果 
周二 ; 电话 拜访 客户 ， 收 集 并 汇总 客户 在 产品 使 用 过 程 中 的 问题 周二 : 电话 拜访 客户 ， 收 集 并 汇总 客户 在 产品 使 用 过 程 中 的 问题 
周三 : 联系 企业 内 训 讲师 ， 初 审 内 训 大 网， 安排 内 训 时 间 、 地 点 等 周三 :与 经 理 一 起 参加 公司 中 高 层 干部 会 议 ， 讨 论 公司 规划 
周 四 : 整理 研发 项 目的 文档 ， 主 持 并 参与 项 目 经 理会 议 周 四 : 整理 研发 项 目的 文档 ， 主 持 并 参与 项 目 经 理会 议 
周 五 : 收集 各 项 目 组 进展 报告 ， 配 合 经 理 抽 查 项 目 完成 情况 周 五 : 收集 各 项 目 组 进展 报告 ， 配 合 经 理 抽查 项 目 完成 情况 
周 六 : 加 班 ， 协 助 组 织 并 参与 企业 内 训 周 六 : 休息 
过 到 的 问题 : 遇 到 的 问题 : 
- 切 顺 利 ! - 切 顺 利 ! 
收获 和 体会 : 收获 和 体会 : 
这 周 好 忙 ， 周 一 军 周 五 都 加 班 ! 这 周 好 忙 ， 周 一 至 周 五 都 加 班 ! 

















图 7-1 工作 周报 示意 图 


Sunny 公 司 的 开发 人 员 通 过 对 问题 进行 仔细 分 析 ， 决 定 按照 如 下 思路 对 工作 周报 模块 进行 重新 
设计 和 实现 : 


(1) 除 了 允许 用 户 创建 新 周报 外 ， 还 允许 用 户 将 创建 好 的 周报 保存 为 模板 ; 


(2) 用 户 在 再 次 创建 周报 时 ， 可 以 创建 全 新 的 周报 ， 还 可 以 选择 合适 的 模板 复制 生成 一 份 相同 
的 周报 ， 然 后 对 新 生成 的 周报 根据 实际 情况 进行 修改 ， 产 生 新 的 周报 。 


只 要 按照 如 上 两 个 步骤 进行 处 理 ， 工 作 周 报 的 创建 效率 将 得 以 大 大 提高 。 这 个 过 程 让 我 们 想 
到 平时 经 常 进行 的 两 个 电脑 基本 操作 : 复制 和 粘贴 ， 快 捷 键 通常 为 Ctrl + C 和 Ctrl +V， 通 过 对 
已 有 对 象 的 复制 和 粘贴 ， 我 们 可 以 创建 大 量 的 相同 对 象 。 如 何在 一 个 面向 对 象 系统 中 实现 对 
象 的 复制 和 粘贴 呢 ? 不 用 着 急 ， 本 章 我 们 介绍 的 原型 模式 正 为 解决 此 类 问题 而 诞生 。 

7.2 原型 模式 概述 

在 使 用 原型 模式 时 ， 我 们 需要 首先 创建 一 个 原型 对 象 ， 再 通过 复制 这 个 原型 对 象 来 创建 更 多 
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同类 型 的 对 象 。 试 想 ， 如 果 连 孙悟空 的 模样 都 不 知道 ， 怎 么 拔 毛 变 小 猴子 呢 ? 原型 模式 的 定 
义 如 下 : 原型 模式 (Prototype Pattern) : 使 用 原型 实例 指定 创建 对 象 的 种 类 ， 并 且 通 过 拷贝 这 些 
原型 创建 新 的 对 象 。 原 型 模式 是 一 种 对 象 创建 型 模式 。 


原型 模式 的 工作 原理 很 简单 : 将 一 个 原型 对 象 传 给 那个 要 发 动 创建 的 对 象 ， 这 个 要 发 动 创建 
的 对 象 通过 请 求 原 型 对 象 描 贝 自己 来 实现 创建 过 程 。 由 于 在 软件 系统 中 我 们 经 常会 遇 到 需要 
创建 多 个 相同 或 者 相似 对 象 的 情况 ， 因 此 原型 模式 在 丨 实 开 发 中 的 使 用 频率 还 是 非常 高 的 。 
原型 模式 是 一 种 “另类 ”的 创建 型 模式 ， 创 建 克隆 对 象 的 工厂 就 是 原型 类 自身 ， 工 厂 方法 由 克隆 
方法 来 实现 。 


需要 注意 的 是 通过 克隆 方法 所 创建 的 对 象 是 全 新 的 对 象 ， 它 们 在 内 存 中 拥有 新 的 地 址 ， 通 常 
对 克隆 所 产生 的 对 象 进 行 修改 对 原型 对 象 不 会 造成 任何 影响 ， 每 一 个 克隆 对 象 都 是 相互 独立 
的 。 通 过 不 同 的 方式 修改 可 以 得 到 一 系列 相似 但 不 完全 相同 的 对 象 。 


原型 模式 的 结构 如 图 7-2 所 示 : 
图 7-2 原型 模式 结构 图 
在 原型 模式 结构 图 中 包含 如 下 几 个 角色 : 


ePrototype (抽象 原型 类 ) : 它 是 声明 克隆 方法 的 接口 ， 是 所 有 具体 原型 类 的 公共 父 类 ， 可 以 
是 抽象 类 也 可 以 是 接口 ， 甚 至 还 可 以 是 具体 实现 类 。 


e ConcretePrototype (具体 原型 类 ) : 它 实现 在 抽象 原型 类 中 声明 的 克隆 方法 ， 在 克隆 方法 中 
返回 自己 的 一 个 克隆 对 象 。 


e@ Client (客户 类 ) : 让 一 个 原型 对 象 克隆 自身 从 而 创建 一 个 新 的 对 象 ， 在 客户 类 中 只 需要 直 
接 实 例 化 或 通过 工厂 方法 等 方式 创建 一 个 原型 对 象 ， 再 通过 调用 该 对 象 的 克隆 方法 即 可 得 到 
多 个 相同 的 对 象 。 由 于 客户 类 针对 抽象 原型 类 Prototype 编 程 ， 因 此 用 户 可 以 根据 需要 选择 具体 
原型 类 ， 系 统 具有 较 好 的 可 扩展 性 ， 增 加 或 更 换 具 体 原 型 类 都 很 方便 。 


原型 模式 的 核心 在 于 如 何 实现 克隆 方法 ， 下 面 将 介绍 两 种 在 Java 语 言 中 常用 的 克隆 实现 方法 : 
1. 通 用 实现 方法 


通用 的 克隆 实现 方法 是 在 具体 原型 类 的 克隆 方法 中 实例 化 一 个 与 自身 类 型 相同 的 对 象 并 将 其 
返回 ， 并 将 相关 的 参数 传 入 新 创建 的 对 象 中 ， 保 证 它们 的 成 员 属 性 相同 。 示 意 代码 如 下 所 
示 : 


class ConcretePrototype implements Prototype 


{ 
private String attr; // 成 员 属 性 
public void setAttr(String attr) 


{ 
this.attr = attr; 


} 
public String getAttr() 
{ 


return this.attr; 


} 
public Prototype clone() // 克 隆 方法 


{ 
Prototype prototype = new ConcretePrototype(); // 创 建新 对 象 


prototype.setAttr(this.attr); 
return prototype; 
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能 否 将 上 述 代 码 中 的 clone() 方 法 写成 : public Prototype clone() { return this; }? 给 出 你 的 理由 。 


在 客户 类 中 我 们 只 需要 创建 一 个 ConcretePrototype 对 象 作为 原型 对 象 ， 然 后 调用 其 clone() 方 法 
即 可 得 到 对 应 的 克隆 对 象 ， 如 下 代码 所 示 : 


Prototype obj1 = new ConcretePrototype() ; 
obj1.setAttr("Sunny"); 
Prototype obj2 = obji.clone(); 


这 种 方法 可 作为 原型 模式 的 通用 实现 ， 它 与 编程 语言 特性 无 关 ， 任 何 面向 对 象 语 言 都 可 以 使 
用 这 种 形式 来 实现 对 原型 的 克隆 。 

1. Java 语 言 提供 的 clone() 方 法 
学 过 Java 语 言 的 人 都 知道 ， 所 有 的 Java 类 都 继承 自 java.lang.Object。 事 实 上 ，Object 类 提供 一 个 
clone() 方 法 ， 可 以 将 一 个 Java 对 象 复制 一 份 。 因 此 在 Java 中 可 以 直接 使 用 Object 提供 的 clone() 方 
法 来 实现 对 象 的 克隆 ，Java 语 言 中 的 原型 模式 实现 很 简单 。 
需要 注意 的 是 能 够 实现 克隆 的 Java 类 必须 实现 一 个 标识 接口 Cloneable， 表 示 这 个 Java 类 支持 被 
复制 。 如 果 一 个 类 没有 实现 这 个 接口 但 是 调用 了 clone() 方 法 ，Java 编 译 器 将 抛 出 一 个 
CloneNotSupportedException 弄 常 。 如 下 代码 所 示 : 


class ConcretePrototype implements Cloneable 


{ 
public Prototype clone() 
{ 
Object object = null; 
try { 
object = super.clone(); 
} catch (CloneNotSupportedException exception) { 
System.err.println("Not Support cloneable"); 
} 
return (Prototype )object; 
} 
} 


在 客户 端 创建 原型 对 象 和 克隆 对 象 也 很 简单 ， 如 下 代码 所 示 : 


Prototype obj1 
Prototype obj2 


new ConcretepPrototype() ， 
obj1.clone(); 


一 般 而 言 ，Java 语 言 中 的 clone() 方 法 满足 : 

(1) 对 任何 对 象 X， 都 有 x.clone() != X， 即 克隆 对 象 与 原型 对 象 不 是 同一 个 对 象 ; 

(2) 对 任何 对 象 X， 都 有 x.clone().getClass() == x.getClass()， 即 克隆 对 象 与 原型 对 象 的 类 型 一 
样 ; 
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(3) 如 果 对 象 x 的 equals() 方 法 定义 恰当 ， 那 么 Xx.clone().equals(X) 应 该 成 立 。 

为 了 获取 对 象 的 一 份 捞 贝 ， 我 们 可 以 直接 利用 Object 类 的 clone() 方 法 ， 具 体 步 骤 如 下 : 
(1) 在 派生 类 中 履 盖 基 类 的 clone() 方 法 ， 并 声明 为 public ; 

(2) 在 派生 类 的 clone() 方 法 中 ， 调 用 super.clone() ; 

(3) 派 生 类 需 实现 Cloneable 接 口 。 


此 时 ，Object 类 相当 于 抽象 原型 类 ， 所 有 实现 了 Cloneable 接 口 的 类 相当 于 具体 原型 类 。 
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对 象 的 克隆 一 原型 模式 〈 二 ) 
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7.3 完整 解决 方案 


Sunny 公 司 开 发 人 员 决 定 使 用 原型 模式 来 实现 工作 周报 的 快速 创建 ， 快 速 创建 工作 周报 结构 图 
如 图 7-3 所 示 : 









Object ”Cloneable 
+ clone () : Object | | 
A 
WeeNyLog 
-name  : String 
-date :String 






- Content : String 
+ setName (String name) 

+ setDate {String date) 

+ setContent (String content) : 





+ getContent () 
+ clone() 


图 7-3 快速 创建 工作 周报 结构 图 


在 图 7-3 中 ，WeeklyLog 充 当 具 体 原型 类 ，Object 类 充当 抽象 原型 类 ，clone() 方 法 为 原型 方法 。 
WeeklyLog 类 的 代码 如 下 所 示 : 


// 工 作 周报 WeeklyLog : 具体 原型 类 ， 考 虑 到 代码 的 可 读 性 和 易 理 解 性 ， 只 列 出 部 分 与 模式 
class WeeklyLog implements Cloneable 
{ 
private String name; 
private String date; 
private String content; 
public void setName(String name) { 
this.name = name; 
} 
public void setDate(String date) { 
this.date = date; 


} 

public void setContent(String content) { 
this.content = content; 

} 


public String getName() { 
return (this.name); 
} 


public String getDate() { 
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public 


return (this.date); 


String getContent() { 
return (this.content ) ， 


} 
// 克 隆 方法 clone()， 此 处 使 用 Java 语 言 提供 的 克隆 机 制 


public 
{ 


} 


weeklyLog clone() 


Object obj = null; 

try 

{ 
obj = super.clone(); 
return (WeeklyLog)obj; 


catch(CloneNotSupportedException e) 


{ 
System.out.println(" 不 支持 复制 ! ")， 
return null; 


编写 如 下 客户 端 测 试 代 码 : 


class Client 


{ 


static void main(String args[]) 


WeeklyLog 1og_previous = new WeeklyLog(); // 创 建 原型 对 甸 
1og_previous .setName(" 张 无 辟 " ) 
log_previous.setDate(" 第 12 周 ")， 
log_previous.setContent(" 这 周 工 作 很 性 ， 每 天 加 班 | ")， 


System.out.println("**** 周 报 ****")， 

System.out.printljn(" 周 次 :" + 1og _previous .getDate() ); 
System.out.println(" 姓 名 :" + 1log_previous.getName()); 
System.out.println(" 内 容 :" + 1og_previous .getContent ( 
System.out.printjn(--------------- ") 


WeeklyLog log_new; 

1og_new = log_previous.clone(); // 调 用 克隆 方法 创建 克隆 对 甸 
log_new.setDate(" 第 13 周 ")， 
System.out.println("**** 周 报 ****")， 
System.out.println(" 周 次 :" + log_new.getDate()); 
System.out.println(" 姓 名 :" + log_new.getName()); 
System.out .println(" 内 容 :" + 1og_new.getCcontent()); 


编译 并 运行 程序 ， 输 出 结果 如 下 : 


public 
{ 
} 
} 
*X*** 火 周报 **** 类 类 
周 次 : 第 12 周 
姓名 : 张无忌 
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内 容 : 这 周 工 作 很 忙 ， 每 天 加 班 ! 
i 
周 次 : 第 13 周 

姓名 : 张无忌 

内 容 : 这 周 工 作 很 忙 ， 每 天 加 班 ! 


通过 已 创建 的 工作 周报 可 以 快速 创建 新 的 周报 ， 然 后 再 根据 需要 修改 周报 ， 无 须 再 从 头 开始 


创建 。 原 型 模式 为 工作 流 系 统 中 任务 单 的 快速 生成 提供 了 一 种 解决 方案 。 


本 
心 


如 果 在 Client 类 的 main(0) 函 数 中 增加 如 下 几 条 语句 : 


System.out.println(log_previous == lo0og_new); 
System.out.println(log_previous.getDate() == log_new.getDate()); 
System.out.println(log_previous.getName() == log_new.getName()); 


System.out.println(log_previous.getContent() == log_new.getContent() 


预测 这 些 语句 的 输出 结果 。 
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对 象 的 克隆 
对 象 的 克隆 


7.4 带 附件 的 周报 


通过 引入 原型 模式 ，Sunny 软 件 公司 OA 系统 支持 工作 周报 的 快速 克隆 ， 极 大 提高 了 工作 周报 
的 编写 效率 ， 受 到 员工 的 一 致 好 评 。 但 有 员工 又 发 现 一 个 问题 ， 有些 工作 周报 带 有 附件 ， 例 
如 经 理 助理 “小 龙 女 ”的 周报 通常 附 有 本 周 项 目 进展 报告 汇总 表 、 本 周 客户 反馈 信息 汇总 表 等 ， 
如 果 使 用 上 述 原型 模式 来 复制 周报 ， 周 报 虽 然 可 以 复制 ， 但 是 周报 的 附件 并 不 能 复制 ， 这 是 
由 于 什么 原因 导致 的 呢 ? 如 何 才 能 实现 周报 和 附件 的 同时 复制 呢 ? 我 们 在 本 节 将 讨论 如 何 解 
决 这 些 问 题 。 


原型 模式 (三 ) 
原型 模式 (三 ) 





在 回答 这 些 问题 之 前 ， 先 介绍 一 下 两 种 不 同 的 克隆 方法 ， 浅 克隆 (ShallowClone) 和 深 克 隆 
(DeepClone)。 在 Java 语 言 中 ， 数 据 类 型 分 为 值 类 型 (基本 数据 类 型 ) 和 引用 类 型 ， 值 类 型 包括 
int、double、byte、boolean、char 等 简单 数据 类 型 ， 引 用 类 型 包括 类 、 接 口 、 数 组 等 复杂 类 

型 。 浅 克隆 和 深 克 隆 的 主要 区 别 在 于 是 否 支 持 引 用 类 型 的 成 员 变 量 的 复制 ， 下 面 将 对 两 者 进 


行 详细 介绍 。 
1. 浅 克隆 


在 浅 克隆 中 ， 如 果 原 型 对 象 的 成 员 变 量 是 值 类 型 ， 将 复制 一 份 给 克隆 对 象 ; 如 果 原 型 对 象 的 
成 员 变 量 是 引用 类 型 ， 则 将 引用 对 象 的 地 址 复制 一 份 给 克隆 对 象 ， 也 就 是 说 原型 对 象 和 克隆 
对 象 的 成 员 变 量 指向 相同 的 内 存 地 址 。 简 单 来 说 ， 在 浅 克 隆 中 ， 当 对 象 被 复制 时 只 复制 它 本 
身 和 其 中 包含 的 值 类 型 的 成 员 变量 ， 而 引用 类 型 的 成 员 对 象 并 没有 复制 ， 如 图 7-4 所 示 : 








引用 类 型 成 员 变 其 
复制 地 十 


原型 对 象 .复制 _ 克隆 对 象 


值 类 型 成 员 变 其 


图 7-4 浅 克 隆 示 意图 


在 Java 语 言 中 ， 通 过 禾 盖 Object 类 的 clone0) 方 法 可 以 实现 浅 克 隆 。 为 了 让 大 家 更 好 地 理解 浅 克 
隆 和 深交 隆 的 区 别 ， 我 们 首先 使 用 浅 克 隆 来 实现 工作 周报 和 附件 类 的 复制 ， 其 结构 如 图 7-5 所 
示 : 
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Object 
7 
+ clone () :Object : | | 
Attachment WeeklyLog 
a 
+ SetName (String name) : void a i ee 
+ getName () : String es 
+ download () -void <]- Content :String 





十 


setAttachment (Attachment attachment) : void 
setName (String name) : void 
setDate (String date) : void 
setContent (String content) : void 
getAttachment () : Atachment 
getName () : String 
getDate () : String 
gatContent () : String 
clone () : WeeklyLog 


+ 
+ 
+ 
+ 
+ 
+ 
+ 
十 


图 7-5 带 附 件 的 周报 结构 图 ( 浅 克 隆 ) 
附件 类 Attachment 代 码 如 下 : 


// 附 件 类 
class Attachment 


{ 
private String name; // 附 件 名 
public void setName(String name ) 


this.name = name; 
ee String getName() 
, return this.name; 
ee void download() 
System.out.println(" 下 载 附件 ,文件 名 为 " + name ) ; 


} 
修改 工作 周报 类 WeeklyLog， 修 改 后 的 代码 如 下 : 


// 工 作 周报 WeeklyLog 
class WeeklyLog implements Cloneable 


// 为 了 简化 设计 和 实现 ， 假 设 一 份 工作 周报 中 只 有 一 个 附件 对 象 ， 实 际 情况 中 可 以 包含 

private Attachment attachment; 
private String name; 

private String date; 
private String content; 

public void setAttachment(Attachment attachment) { 

this.attachment = attachment; 

} 


public void setName(String name) { 
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} 
public 


} 
public 


} 


this.name = name; 


void setDate(String date) { 
this.date = date; 


void setContent(String content) { 
this.content = content; 


public Attachment getAttachment(){ 


} 
public 


public 


} 
public 


return (this.attachment); 


String getName() { 
return (this.name); 


String getDate() { 
return (this.date); 


String getContent() { 
return (this.content ) ， 


} 
// 使 用 clone( ) 方 法 实现 浅 克 隆 


public WeeklyLog clone() 
{ 
Object obj = null; 
try 
{ 
obj = super.clone(); 
return (WeeklyLog)obj; 
catch(CloneNotSupportedException e) 
{ 
System.out.println(" 不 支持 复制 ! ")， 
return null; 
} 
} 
} 
客户 端 代码 如 下 所 示 : 


class Client 


{ 
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static void main(String args[]) 


WeeklyLog log_previous, log_new; 

log_previous = new WeeklyLog(); // 创 建 原型 对 象 
Attachment attachment = new Attachment(); // 创 建 附件 对 名 
1og_previous .setAttachment(attachment ); // 将 附件 添加 到 周 
1og_new = log_previous.clone(); // 调 用 克隆 方法 创建 克隆 对 甸 
// 比 较 周报 

System.out.println(" 周 报 是 否 相 同 ? " + (log_previous == 
// 比 较 附 件 

System.out.println(" 附 件 是 否 相 同 ? " + (log_previous.get 
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} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


周报 是 否 相 同 ? false 
附件 是 否 相同 ? true 


由 于 使 用 的 是 浅 克 隆 技术 ， 因 此 工作 周报 对 象 复制 成 功 ， 通 过 “==” 比 较 原 型 对 象 和 克隆 对 象 
的 内 存 地 址 时 输出 false ; 但 是 比较 附件 对 象 的 内 存 地 址 时 输出 true， 说 明 它 们 在 内 存 中 是 同一 
个 对 象 。 
2. 深 克隆 


在 深 克 隆 中 ， 无 论 原型 对 象 的 成 员 变 量 是 值 类 型 还 是 引用 类 型 ， 都 将 复制 一 份 给 克隆 对 象 ， 
深 克 隆 将 原型 对 象 的 所 有 引用 对 象 也 复制 一 份 给 克隆 对 象 。 简 单 来 说 ， 在 深 克 隆 中 ， 除 了 对 
象 本 身 被 复制 外 ， 对 象 所 包含 的 所 有 成 员 变 量 也 将 复制 ， 如 图 7-6 所 示 : 


引用 类 型 成 员 变量 引用 类 型 成 员 变量 


原型 对 象 


值 类 型 成 员 变 量 





图 7-6 深 克 隆 示意 图 


在 Java 语 言 中 ， 如 果 需 要 实现 深 克隆 ， 可 以 通过 序列 化 (Serialization) 等 方式 来 实现 。 序 列 化 就 
是 将 对 象 写 到 流 的 过 程 ， 写 到 流 中 的 对 象 是 原 有 对 象 的 一 个 找 贝 ， 而 原 对 象 仍 然 存 在 于 内 存 
中 。 通 过 序列 化 实现 的 拷贝 不 仅 可 以 复制 对 象 本 身 ， 而 且 可 以 复制 其 引用 的 成 员 对 象 ， 因 此 
通过 序列 化 将 对 象 写 到 一 个 流 中 ， 再 从 流 里 将 其 读 出 来 ， 可 以 实现 深 克隆 。 需 要 注意 的 是 能 
够 实现 序列 化 的 对 象 其 类 必须 实现 Serializable 接 口 ， 否 则 无 法 实现 序列 化 操作 。 下 面 我 们 使 用 
深 克 隆 技术 来 实现 工作 周报 和 附件 对 象 的 复制 ， 由 于 要 将 附件 对 象 和 工作 周报 对 象 都 写 入 流 
中 ， 因 此 两 个 类 均 需 要 实现 Serializable 接 口 ， 其 结构 如 图 7-7 所 示 : 
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”Serializable 





- attachment : Attachment 

+ setName (String name) : void :Sting 

+ getName () : String :Sting 

+ download () : void - String 

setAttachment (Attachment attachment) : void 
setName (String name) : void 
setDate (String date) : void 
setContent (String content) : void 
getAttachment () - Attac hment 



















attachment 


+ getName () -String 
+ getDate () : String 
+ getContent () -String 
+ deepClone () : WeeklyLog 


图 7-7 带 附件 的 周报 结构 图 ( 深 克 隆 ) 
修改 后 的 附件 类 Attachment 代 码 如 下 : 


Import java.io.*; 
// 附 件 类 
class Attachment implements Serializable 


{ 
private String name; // 附 件 名 
public void setName(String name ) 


‘ 


this.name = name; 


public String getName() 


{ 
return this.name; 
} 
public void download() 
{ 
System.out.println(" 下 载 附件 ,文件 名 为 " + name ) ; 
} 


} 


工作 周报 类 WeeklyLog 不 再 使 用 Java 自 带 的 克隆 机 制 ， 而 是 通过 序列 化 来 从 头 实现 对 象 的 深 克 
隆 ， 我 们 需要 重新 编写 clone() 方 法 ， 修 改 后 的 代码 如 下 : 


import java.io.*,; 


// 工 作 周 报 类 
class WeeklyLog implements Serializable 
{ 


private Attachment attachment ; 
private String name; 
private String date; 
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private String content; 


public 


} 
public 


} 
public 


} 
public 


} 
public 


} 
public 


} 
public 


} 
public 


void setAttachment(Attachment attachment) { 
this.attachment = attachment; 


void setName(String name) { 
this.name = name; 


void setDate(String date) { 
this.date = date; 


void setContent(String content) { 
this.content = content; 


Attachment getAttachment(){ 
return (this.attachment); 


String getName() { 
return (this.name); 


String getDate() { 
return (this.date); 


String getContent() { 
return (this.content ) ， 


} 
// 使 用 序列 化 技术 实现 深 克 隆 


public WeeklyLog deepClone() throws IOException, ClassNotFou 
// 将 对 象 写 入 流 中 
ByteArrayOutputStream bao=new ByteArrayOutputStream() 
ObjectOutputStream oos=new ObjectOutputStream(bao); 
o0s.writeObject(this); 
// 将 对 象 从 流 中 取出 
ByteArrayInputStream bis=new ByteArrayInputStream(bao 
ObjectInputStream ois=new ObjectInputStream(bis ) 
return (weeklyLog)ois.readobject(); 
} 
} 
客户 端 代码 如 下 所 示 : 


class Client 


{ 
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static void main(String args[]) 


WeeklyLog log_previous, log_new = null; 
log_previous = new WeeklyLog(); // 创 建 原型 对 象 
Attachment attachment = new Attachment(); // 创 建 附件 对 名 
1og_previous .setAttachment(attachment ); // 将 附件 添加 到 周 
try 
{ 

1og_new = log_previous.deepClone(); // 调 用 深 克 隆 


对 象 的 克隆 一 一 原型 模式 (三 ) 


catch(Exception e) 


System.err.println(" 克 隆 失败 1 ")， 


} 

// 比 较 周报 

System.out.println(" 周 报 是 否 相 同 ? " + (log_previous == 
// 比 较 附 件 


System.out.println(" 附 件 是 否 相 同 ? " + (log_previous.get 


| 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


周报 是 否 相 同 ? false 
附件 是 否 相同 ? false 


从 输出 结果 可 以 看 出 ， 由 于 使 用 了 深 克 隆 技 术 ， 附 件 对 象 也 得 以 复制 ， 因 此 用 “==” 比 较 原 型 

对 象 的 附件 和 克隆 对 象 的 附件 时 输出 结果 均 为 false。 深 克隆 技术 实现 了 原型 对 象 和 克隆 对 象 的 
完全 独立 ， 对 任意 克隆 对 象 的 修改 都 不 会 给 其 他 对 象 产生 影响 ， 是 一 种 更 为 理想 的 克隆 实现 
方式 。 

扩展 

Java 语 言 提供 的 Cloneable 接 口 和 Serializable 接 口 的 代码 非常 简单 ， 它 们 都 是 空 接口 ， 这 种 


空 接口 也 称 为 标识 接口 ， 标 识 接 口中 没有 任何 方法 的 定义 ， 其 作用 是 告诉 JRE 这 些 接 口 的 
实现 类 是 否 具 有 某 个 功能 ， 如 是 否 支 持 克隆 、 是 否 支 持 序 列 化 等 。 
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对 象 的 克隆 一 一 原型 模式 (四) 
对 象 的 克隆 一 一 原型 模式 (四) 


7.5 原型 管理 器 的 引入 和 实现 
原型 管理 器 (Prototype Managem 是 将 多 个 原型 对 象 存储 在 一 个 集合 中 供 客 户 端 使 用 ， 它 是 一 个 
专门 负责 克隆 对 象 的 工厂 ， 其 中 定义 了 一 个 集合 用 于 存储 原型 对 象 ， 如 果 需 要 某 个 原型 对 象 


的 一 个 克隆 ， 可 以 通过 复制 集合 中 对 应 的 原型 对 象 来 获得 。 在 原型 管理 器 中 针对 抽象 原型 类 
进行 编程 ， 以 便 扩展 。 其 结构 如 图 7-8 所 示 : 










Prototype 


+ clone () : Prototype 
A 


<<crep te>> 


PrototypeManager 
- prototypeTable : Hashtable 


ConcretePrototypeA ConcretePrototypeB 


+ add (String key, Prototype prototype) : void 
+ get (String key) : Prototype 








+ clone () : Prototype + clone () : Prototype 





图 7-8 带 原型 管理 器 的 原型 模式 


下 面 通过 模拟 一 个 简单 的 公文 管理 器 来 介绍 原型 管理 器 的 设计 与 实现 : Sunny 软 件 公司 在 日 党 
办 公 中 有 许多 公文 需要 创建 、 递 交 和 审批 ， 例 如 《可 行 性 分 析 报告 》、《 立 项 建议 书 》、 
《软件 需求 规格 说 明 书 》、《 项 目 进展 报告 》 等 ， 为 了 提高 工作 效率 ， 在 OA 系统 中 为 各 类 公 
文 均 创建 了 模板 ， 用 户 可 以 通过 这 些 模板 快速 创建 新 的 公文 ， 这 些 公文 模板 需要 统一 进行 管 
理 ， 系 统 根据 用 户 请 求 的 不 同 生成 不 同 的 新 公文 。 


我 们 使 用 带 原 型 管理 器 的 原型 模式 实现 公文 管理 器 的 设计 ， 其 结构 如 图 7-9 所 示 : 
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A 
3 OfficialDocument 
+ clone () :OffcialDocument 
+ display () : void 
下 
PrototypeManager Ye | 
IT 


- PrototypeManager () 

+ addofficialDocument (String key, : void 
OfficialDocument doc) 

+ getOfficialDocument (String key) : OfficialDocumert 、 

+ getPrototypeManager () -PrototypeManager |-、 


~ 
~ 


retum ((OfficialDocument)ht.get(key)).clone()}: | 


+ Clone () : OfficialDocument 
+ display () : void 





+ Clone () :OfficialDocument 
+ display () : void 





图 7-9 公文 管理 器 结构 图 
以 下 是 实现 该 功能 的 一 些 核心 代码 ， 考 虑 到 代码 的 可 读 性 ， 我 们 对 所 有 的 类 都 进行 了 简化 : 
import java.util.*,; 


// 抽 象 公文 接口 ， 也 可 定义 为 抽象 类 ， 提 供 clLlone() 方 法 的 实现 ， 将 业务 方法 声明 为 抽象 方 疙 
interface OfficialDocument extends Cloneable 


{ 


public officialDocument clone(); 
public void display(); 
} 


// 可 行 性 分 析 报 告 (Feasibility Analysis Report) 类 
class FAR implements OfficialDocument 


{ 
public OfficialDocument clone() 
{ 
OfficialDocument far = null; 
try 
{ 
far = (OfficialDocument)super.clone(); 
catch(CloneNotSupportedException e) 
{ 
System.out.println(" 不 支持 复制 ! ")， 

} 
return far; 

} 

public void display() 

{ 
System.out ,println(" 《可 行 性 分 析 报 告 》" ) ， 

} 
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} 


// 软 件 需求 规格 说 明 书 (Software Requirements Specification) 类 
class SRS implements OfficialDocument 


{ 
public OfficialDocument clone() 
{ 
OfficialDocument srs = null; 
try 
{ 
srs = (OfficialDocument)super.clone(); 
catch(CloneNotSupportedException e) 
{ 
System.out.println(" 不 支持 复制 ! ")， 
} 
return srs; 
} 
public void display() 
{ 
System.out,println("《 软 件 需 求 规格 说 明 书 》"); 
} 
} 


// 原 型 管理 器 (使 用 馈 汉 式 单 例 实现 ) 
class PrototypeManager 


{ 
// 定 义 一 个 Hashtable， 用 于 存储 原型 对 象 
private Hashtable ht=new Hashtable(); 
private static PrototypeManager pm = new PrototypeManager(); 


// 为 Hashtable 增 加 公文 对 象 
private PrototypeManager() 


ht.put("far",new FAR()); 
ht.put("srs",new SRS()); 
} 
// 增 加 新 的 公文 对 象 
public void addofficialDocument(String key,OfficialDocument ' 
ht.put(key, doc); 
} 


// 通 过 浅 克 隆 获取 新 的 公文 对 象 
public OfficialDocument getofficialDocument(String key) 
{ 


} 


return ((OfficialDocument)ht.get(key)).clone(); 


public static PrototypeManager getPrototypeManager() 
{ 
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return pm; 


} 
客户 端 代码 如 下 所 示 : 


class Client 
{ 
public static void main(String args[]) 
{ 
// 获 取 原 型 管理 器 对 象 
PrototypeManager pm = PrototypeManager .getPrototypeMa 


OfficialDocument doc1,doc2,doc3,doc4; 


doc1 = pm.getofficialDocument("far"); 
doci1.display(); 

doc2 = pm.getofficialDocument("far"); 
doc2.display(); 
System.out.println(doci == doc2); 


doc3 = pm.getofficialDocument("srs"); 
doc3.display(); 

doc4 = pm.getofficialDocument("srs"); 
doc4.display(); 
System,out,println(doc3 == doc4); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


《可 行 性 分 析 报 告 》 

《可 行 中 和 分 析 报 告 》 
false 

《软件 需求 规格 说 明 书 》 

《软件 需求 规格 说 明 书 》 
false 


在 PrototypeManager 中 定义 了 一 个 Hashtable 类 型 的 集合 对 象 ， 使 用 “ 键 值 对 ”来 存储 原型 对 象 ， 
客户 端 可 以 通过 Key (如 “far” 或 “srs”) 来 获取 对 应 原型 对 象 的 克隆 对 象 。PrototypeManager 类 
提供 了 类 似 工 厂 方法 的 getOfficialDocumentO 方 法 用 于 返回 一 个 克隆 对 象 。 在 本 实例 代码 中 ， 
我 们 将 PrototypeManager 设 计 为 单 例 类 ， 使 用 饿 汉 式 单 例 实 现 ， 确 保 系 统 中 有 且 仅 有 一 个 
PrototypeManager 对 象 ， 有 利于 节省 系统 资源 ， 并 可 以 更 好 地 对 原型 管理 器 对 象 进行 控制 
思 
如 果 需 要 增加 一 种 新 类 型 的 公文 ， 如 《项 目 进 展 报 告 》(Project Progress Report, PPR)， 公 
文 管理 器 系统 源 代码 如 何 修改 ， 动 手 实践 你 的 修改 方案 。 


7.6 原型 模式 总 结 

原型 模式 作为 一 种 快速 创建 大 量 相同 或 相似 对 象 的 方式 ， 在 软件 开发 中 应 用 较为 广泛 ， 很 多 
人 
用 效果 和 适用 情况 进行 简单 的 总 结 。 
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1. 主 要 优点 
原型 模式 的 主要 优点 如 下 : 


(1) 当 创 建新 的 对 象 实例 较为 复杂 时 ， 使 用 原型 模式 可 以 简化 对 象 的 创建 过 程 ， 通 过 复制 一 个 
已 有 实例 可 以 提高 新 实例 的 创建 效率 。 


(2) 扩展 性 较 好 ， 由 于 在 原型 模式 中 提供 了 抽象 原型 类 ， 在 客户 端 可 以 针对 抽象 原型 类 进行 纺 
程 ， 而 将 具体 原型 类 写 在 配置 文件 中 ， 增 加 或 减少 产品 类 对 原 有 系统 都 没有 任何 影响 。 

(3) 原型 模式 提供 了 简化 的 创建 结构 ， 工 厂 方法 模式 常常 需要 有 一 个 与 产品 类 等 级 结构 相同 的 
工厂 等 级 结构 ， 而 原型 模式 就 不 需要 这 样 ， 原 型 模式 中 产品 的 复制 是 通过 封装 在 原型 类 中 的 
克隆 方法 实现 的 ， 无 须 专门 的 工厂 类 来 创建 产品 。 


(4) 可 以 使 用 深 克 隆 的 方式 保存 对 象 的 状态 ， 使 用 原型 模式 将 对 象 复制 一 份 并 将 其 状态 保存 起 
来 ， 以 便 在 需要 的 时 候 使 用 (如 恢复 到 菜 一 历史 状态 ) ， 可 辅助 实现 撤销 操作 。 


2. 主 要 缺点 
原型 模式 的 主要 缺点 如 下 : 


(1) 需要 为 每 一 个 类 配备 一 个 克隆 方法 ， 而 且 该 克隆 方法 位 于 一 个 类 的 内 部 ， 当 对 已 有 的 类 进 
行 改造 时 ， 需 要 修改 源 人 代码， 违背 了 “ 开 闭 原则 ”。 


(2) 在 实现 深 克 隆 时 需要 编写 较为 复杂 的 代码 ， 而 且 当 对 象 之 间 存 在 多 重 的 谋 套 引用 时 ， 为 了 
实现 深 克 隆 ， 每 一 层 对 象 对 应 的 类 都 必须 支持 深 克 隆 ， 实 现 起 来 可 能 会 比较 麻烦 。 


3. 适 用 场景 在 以 下 情况 下 可 以 考虑 使 用 原型 模式 : 

(1) 创建 新 对 象 成 本 较 大 (如 初始 化 需要 占用 较 长 的 时 间 ， 占 用 太 多 的 CPU 资源 或 网 络 资 
源 ) ， 新 的 对 象 可 以 通过 原型 模式 对 已 有 对 象 进 行 复制 来 获得 ， 如 果 是 相似 对 象 ， 则 可 以 对 
其 成 员 变 量 稍 作 修改 。 


(2) 如 果 系 统 要 保存 对 象 的 状态 ， 而 对 象 的 状态 变化 很 小 ， 或 者 对 凤 本 身 占 用 内 存 较 少 时 ， 可 
以 使 用 原型 模式 配合 备忘录 模式 来 实现 。 


(3) 需要 避免 使 用 分 层次 的 工厂 类 来 创建 分 层次 的 对 象 ， 并 且 类 的 实例 对 象 只 有 一 个 或 很 少 的 
几 个 组 合 状态 ， 通 过 复制 原型 对 象 得 到 新 实例 可 能 比 使 用 构造 函数 创建 一 个 新 实例 更 加 方 
便 。 


练习 
设计 并 实现 一 个 客户 类 Customer， 其 中 包含 一 个 名 为 客户 地 址 的 成 员 变 量 ， 客 户 地 址 的 类 


型 为 Address， 用 浅 克 隆 和 深 克 隆 分 别 实现 Customer 对 象 的 复制 并 比较 这 两 种 克隆 方式 的 
异同 。 
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建造 者 模式 -Builder Pattern 
建造 者 模式 -Builder Pattern 


建造 者 模式 -Builder Pattern 【学 习 难 度 : 克 克 交友 六 ， 使 用 频率 : 真 丰 亦 认 六 】 
e@ 建造 者 模式 -Builder Pattern 
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没有 人 买 车 会 只 买 一 个 轮胎 或 者 方向 盘 ， 大 家 买 的 都 是 一 辆 包含 轮胎 、 方 向 盘 和 发 动机 等 多 
个 部 件 的 完整 汽车 。 如 何 将 这 些 部 件 组 装 成 一 辆 完整 的 汽车 并 返回 给 用 户 ， 这 是 建造 者 模式 
需要 解决 的 问题 。 建 造 者 模式 又 称 为 生成 器 模式 ， 它 是 一 种 较为 复杂 、 使 用 频率 也 相对 较 低 
的 创建 型 模式 。 建 造 者 模式 为 客户 端 返回 的 不 是 一 个 简单 的 产品 ， 而 是 一 个 由 多 个 部 件 组 成 
的 复杂 产品 。 


8.1 游戏 角色 设计 


Sunny 软 件 公司 游戏 开发 小 组 决定 开发 一 款 名 为 《Sunny 群 侠 传 》 的 网 络 游戏 ， 该 游戏 采用 主 
流 的 RPG(Role Playing Game, 角 色 扮 演 游戏 ) 模 式 ， 玩 家 可 以 在 游戏 中 扮演 虚拟 世界 中 的 一 个 特 
定 角色 ， 和 角色 根据 不 同 的 游戏 情节 和 统计 数据 (如 力量 、 魔 法 、 技 能 等 ) 具有 不 同 的 能 力 ， 
角色 也 会 随 着 不 断 升 级 而 拥有 更 加 强大 的 能 力 。 


作为 RPG 游 戏 的 一 个 重要 组 成 部 分 ， 需 要 对 游戏 角色 进行 设计 ， 而 且 随 着 该 游戏 的 升级 将 不 
断 增 加 新 的 角色 。 不 同类 型 的 游戏 角色 ， 其 性 别 、 脸 型 、 服 装 、 发 型 等 外 部 特性 都 有 所 差 
异 ， 例 如 “天 使 ”拥有 美丽 的 面容 和 披肩 的 长 发 ， 并 身 穿 一 丈 白 裙 ; 而 “恶魔 ”极其 五 陋 ， 留 着 光 
头 并 穿 一 件 刺 眼 的 黑 衣 。 Sunny 公 司 决定 开发 一 个 小 工具 来 创建 游戏 角色 ， 可 以 创建 不 同类 型 
的 角色 并 可 以 灵活 增加 新 的 角色 。 


Sunny 公 司 的 开发 人 员 通 过 分 析 发 现 ， 游 戏 角 色 是 一 个 复杂 对 象 ， 它 包含 性 别 、 脸 型 等 多 个 组 
成 部 分 ， 不 同 的 游戏 角色 其 组 成 部 分 有 所 差异 ， 如 图 8-1 所 示 : 





图 8-1 几 种 不 同 的 游戏 角色 造型 ( 注 : 本 图 中 的 游戏 角色 造型 来 源 于 网 络 ， 特 此 说 明 ) 


无 论 是 何 种 造型 的 游戏 角色 ， 它 的 创建 步骤 都 大 同 小 异 ， 都 需要 逐步 创建 其 组 成 部 分 ， 再 将 
各 组 成 部 分 装配 成 一 个 完整 的 游戏 角色 。 如 何 一 步 步 创 建 一 个 包含 多 个 组 成 部 分 的 复杂 对 
象 ， 建 造 者 模式 为 解决 此 类 问题 而 诞生 。 


8.2 建造 者 模式 概述 


建造 者 模式 是 较为 复杂 的 创建 型 模式 ， 它 将 客户 端 与 包含 多 个 组 成 部 分 (或 部 件 ) 的 复杂 对 
象 的 创建 过 程 分 离 ， 客 户 端 无 须知 道 复杂 对 象 的 内 部 组 成 部 分 与 装配 方式 ， 只 需要 知道 所 需 
建造 者 的 类 型 即 可 。 它 关注 如 何 一 步 一 步 创建 一 个 的 复杂 对 象 ， 不 同 的 具体 建造 者 定义 了 不 
同 的 创建 过 程 ， 且 具体 建造 者 相互 独立 ， 增 加 新 的 建造 者 非常 方便 ， 无 须 修 改 已 有 代码 ， 系 
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统 具 有 较 好 的 扩展 性 。 
建造 者 模式 定义 如 下 : 


建造 者 模式 (Builder Pattern) : 将 一 个 复杂 对 象 的 构建 与 它 的 表示 分 离 ， 使 得 同样 的 构建 过 程 可 


以 创建 不 同 的 表示 。 建 造 者 模式 是 一 种 对 象 创 建 型 模式 。 


建造 者 模式 一 步 一 步 创 建 一 个 复杂 的 对 象 ， 它 允许 用 户 只 通过 指定 复杂 对 象 的 类 型 和 内 容 就 
可 以 构建 它们 ， 用 户 不 需要 知道 内 部 的 具体 构建 细节 。 建 造 者 模式 结构 如 图 8-2 所 示 : 
















| Builder | 

+ buildPartA () 

+ buildPartB () 

+ buildPartC () 

+ getResult () 
A 







builder 





- builder : Builder [~ 
+ construct () 





builderbuildPartA(): 
builderbuildPartB(): 
builderbuildPartC(): 





return buildergetResult(): 


+ getResult () 


图 8-2 建造 者 模式 结构 图 
在 建造 者 模式 结构 图 中 包含 如 下 几 个 角色 : 
e Builder (抽象 建造 者 ) 





: 它 为 创建 一 个 产品 Product 对 象 的 各 个 部 件 指定 抽象 接口 ， 在 该 接 


口中 一 般 声 明 两 类 方法 ， 一 类 方法 是 buildPartX()， 它 们 用 于 创建 复杂 对 象 的 各 个 部 件 ; 另 一 
类 方法 是 getResult()， 它 们 用 于 返回 复杂 对 象 。Builder 既 可 以 是 抽象 类 ， 也 可 以 是 接口 。 


eConcreteBuilder (具体 建造 者 ) 


: 它 实现 了 Builder 接 口 ， 实 现 各 个 部 件 的 具体 构造 和 装配 方 


法 ， 定 义 并 明确 它 所 创建 的 复杂 对 象 ， 也 可 以 提供 一 个 方法 返回 创建 好 的 复杂 产品 对 象 。 


eProduct (产品 角色 ) 
的 内 部 表示 并 定义 它 的 装配 过 程 。 


e@ Director (指挥 者 ) 


: 它 是 被 构建 的 复杂 对 象 ， 包 含 多 个 组 成 部 件 ， 具 体 建 造 者 创建 该 产品 


: 指挥 者 又 称 为 导演 类 ， 它 负责 安排 复杂 对 象 的 建造 次 序 ， 指 挥 者 与 抽 


象 建 造 者 之 间 存 在 关联 关系 ， 可 以 在 其 construct() 建 造 方法 中 调用 建造 者 对 象 的 部 件 构造 与 装 
配方 法 ， 完 成 复杂 对 象 的 建造 。 客 户 端 一 般 只 需要 与 指挥 者 进行 交互 ， 在 客户 端 确 定 具体 建 
造 者 的 类 型 ， 并 实例 化 具体 建造 者 对 象 ( 也 可 以 通过 配置 文件 和 反射 机 制 ) ， 然 后 通过 指挥 


者 类 的 构造 函数 或 者 Setter 方 法 将 该 对 象 传 入 指挥 者 类 中 。 


在 建造 者 模式 的 定义 中 提 到 了 复杂 对 象 ， 那 么 什么 是 复杂 对 象 ? 简单 来 说 ， 复 杂 对 象 是 指 那 
些 包含 多 个 成 员 属性 的 对 象 ， 这 些 成 员 属 性 也 称 为 部 件 或 零件 ， 如 汽车 包括 方向 盘 、 发 动 
机 、 轮 胎 等 部 件 ， 电 子 邮件 包括 发 件 人 、 收 件 人 、 主 题 、 内 容 、 附 件 等 部 件 ， 一 个 典型 的 复 


杂 对 象 类 代码 示例 如 下 : 


class Product {{ 


private String partA; // 定 义 部 件 ， 部 件 可 以 是 任意 类 下 
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private String partB， 

private String partc; 

//partA 的 Getter 方 法 和 Setter 方 法 省 略 

//partB 的 Getter 方 法 和 Setter 方 法 省 略 

//partc 的 Getter 方 法 和 Setter 方 法 省 略 
} 


在 抽象 建造 者 类 中 定义 了 产品 的 创建 方法 和 返回 方法 ， 其 典型 代码 如 下 : 


abstract class Builder { 
// 创 建 产 品 对 象 
protected Product product=new Product(); 


public abstract void buildPartA(); 
public abstract void buildPartB(); 
public abstract void buildPartCc(); 


// 返 回 产品 对 外 
public Product getResult() { 
return product 
} 


} 


在 抽象 类 Builder 中 声明 了 一 系列 抽象 的 buildPartX() 方 法 用 于 创建 复杂 产品 的 各 个 部 件 ， 具 体 
建造 过 程 在 ConcreteBuilder 中 实现 ， 此 外 还 提供 了 工厂 方法 getResult()， 用 于 返回 一 个 建造 好 
的 完 整 产品 PP 9? 


在 ConcreteBuilder 中 实现 了 buildPartX() 方 法 ， 通 过 调用 Product 的 setPartX(0) 方 法 可 以 给 产品 对 象 
的 成 员 属 二 人 ， 不 同 的 具体 建 旭 才 在 实 观 buildParx0 愉 深 时 交尾 愉 区 员 ， 如 setPartX() 方 法 
的 参数 可 能 不 一 样 ， 在 有 些 具 体 建 造 者 类 中 0 实现 (提供 一 个 空 实 

现 ) 。 而 这 些 对 于 客户 端 来 说 都 无 须 关心 ， 客 户 端 只 需 知 道具 体 建 造 者 类 型 即 可 。 


在 建造 者 模式 的 结构 中 还 引入 了 一 个 指挥 者 类 Director， 该 类 主要 有 两 个 作用 : 一 方面 它 隔离 
了 客户 与 创建 过 程 ; 另 一 方面 它 控制 产品 的 创建 过 程 ， 包 括 某 个 buildPartX() 方 法 是 否 被 调用 
以 及 多 个 buildPartX() 方 法 调用 的 先后 次 序 等 。 。 指挥 者 针对 抽象 建造 者 编程 ， 客 户 端 只 需要 知 
道具 体 建造 者 的 类 型 ， 即 可 通过 指挥 者 类 调用 建造 者 的 相关 方法 ， 返 回 一 个 完整 的 产品 对 
象 。 在 实际 生活 中 也 存在 类 似 指 挥 者 一 样 的 角色 ， 如 一 个 客户 去 购买 电脑 ， 电 脑 销售 人 员 相 
当 于 指挥 者 ， 只 要 客户 确定 电脑 的 类 型 ， 电 脑 销售 人 员 可 以 通知 电脑 组 装 人 员 给 客户 组 装 一 
台电 脑 。 指 挥 者 类 的 代码 示例 如 下 : 


class Director { 
private Builder builder; 


public Director(Builder builder) { 
this.builder=builder; 
} 


public void setBuilder(Builder builder) { 
this.builder=builer; 
} 


// 产 品 构 建 与 组 装 方法 
public Product construct() { 
builder .buildpPartA( ); 
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builder .buildPartB(); 
builder .buildPartCcC(); 
return builder .getResult(); 


} 


在 指挥 者 类 中 可 以 注入 一 个 抽象 建造 者 类 型 的 对 象 ， 其 核心 在 于 提供 了 一 个 建造 方法 
construct0， 在 该 方法 中 调用 了 builder 对 象 的 构造 部 件 的 方法 ， 最 后 返回 一 个 产品 对 象 。 


对 于 客户 端 而 言 ， 只 需 关心 具体 的 建造 者 即 可 ， 一 般 情 况 下 ， 客 户 端 类 代码 片段 如 下 所 示 : 


Builder builder = new ConcreteBuilder(); // 可 通过 配置 文件 实现 
Director director = new Director(builder); 
Product product = director.construct(); 


可 以 通过 配置 文件 来 存储 具体 建造 者 类 ConcreteBuilder 的 类 名 ， 使 得 更 换 新 的 建造 者 时 无 须 修 
改 源 代码 ， 系 统 扩展 更 为 方便 。 在 客户 端 代码 中 ， 无 须 关心 产品 对 象 的 具体 组 装 过 程 ， 只 需 
指定 具体 建造 者 的 类 型 即 可 。 

建造 者 模式 与 抽象 工厂 模式 有 点 相似 ， 但 是 建造 者 模式 返回 一 个 完整 的 复杂 产品 ， 而 抽象 工 
厂 模 式 返回 一 系列 相关 的 产品 ; 在 抽象 工厂 模式 中 ， 客 户 端 通过 选择 具体 工厂 来 生成 所 需 对 
象 ， 而 在 建造 者 模式 中 ， 客 户 端 通过 指定 具体 建造 者 类 型 并 指导 Director 类 如 何 去 生 成 对 象 ， 
侧重 于 一 步 步 构 造 一 个 复杂 对 象 ， 然 后 将 结果 返回 。 如 果 将 抽象 工厂 模式 看 成 一 个 汽车 配件 
生产 厂 ， 生 成 不 同类 型 的 汽车 配件 ， 那 么 建造 者 模式 就 是 一 个 汽车 组 装 厂 ， 通 过 对 配件 进行 
组 装 返回 一 辆 完整 的 汽车 。 


本 
心 


如 果 没 有 指挥 者 类 Director， 客 户 端 将 如 何 构建 复杂 产品 ? 


119 


复杂 对 象 的 组 装 与 创建 一 建造 者 模式 〈 二 ) 


复杂 对 象 的 组 装 与 创建 一 一 建造 者 模式 《二 ) 
复杂 对 象 的 组 装 与 创建 一 一 建造 者 模式 《二 ) 


8.3 完整 解决 方案 
Sunny 公 司 开发 人 员 决 定 使 用 建造 者 模式 来 实现 游戏 角色 的 创建 ， 其 基本 结构 如 图 8-3 所 示 : 





图 8-3 游戏 角色 创建 结构 图 


在 图 8-3 中 ，ActorController 充 当 指 挥 者 ，ActorBuilder 充 当 抽 象 建造 者 ，HeroBnuilder、 
AngelBuilder 和 DevilBuilder 充 当 具 体 建 造 者 ，Actor 充 当 复 杂 产 品 。 完 整 代 码 如 下 所 示 : 
/Actor 角 色 类 : 复杂 产品 ， 考 虑 到 代码 的 可 读 性 ， 只 列 出 部 分 成 员 属性 ， 且 成 员 属 性 的 类 型 均 
为 String， 监 实情 况 下 ， 有 些 成 员 属 性 的 类 型 需 自 定义 


class Actor 


{ 
private String type; // 角 色 类 型 
private String sex; // 性 别 
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private String face; // 脸 型 
private String costume; // 服 装 
private String hairstyle; // 发 型 


public void setType(String type) { 
this.type = type; 


} 

public void setSex(String sex) { 
this.sex = sex; 

} 

public void setFace(String face) { 
this.face = face; 

} 

public void setCostume(String costume) { 
this.costume = costume; 

} 


public void setHairstyle(String hairstyle) 
this.hairstyle = hairstyle; 
} 


public String getType() { 
return (this.type); 
} 


public String getSex() { 
return (this.sex); 
} 


public String getFace() { 
return (this.face); 
} 


public String getCostume() { 
return (this.costume); 
} 


public String getHairstyle() { 
return (this.hairstyle); 
} 


} 
// 角 色 建 造 器 : 抽象 建造 者 


abstract class ActorBuilder 


{ 
protected Actor actor = new Actor(); 
public abstract void buildType(); 
public abstract void buildSex(); 
public abstract void buildFace(); 
public abstract void buildCostume( ); 
public abstract void buildHairstyle(); 

// 工 厂 方法 ， 返 回 一 个 完整 的 游戏 角色 对 象 
public Actor createActor() 
{ 
return actor,; 

} 

} 
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// 英 雄 角色 建造 器 : 具体 建造 者 
class HeroBuilder extends ActorBuilder 


{ 
public void buildType() 


actor.setType(" 英 雄 ")， 
ee void buildSsex() 
actor.setSex(" 男 ")，; 

二 void buildFace() 
actor.setFace(" 英 俊 " ) 
ee void buildCostume() 
actor.setCcostume(" 盔 甲 "); 
a void buildHairstyle() 
actor.setHairstyle(" 貌 选 ")， 


} 


// 天 使 角色 建造 器 : 具体 建造 者 
class AngelBuilder extends ActorBuilder 


{ 
public void buildType() 


l actor.setType(" 天 使 ")， 

i void buildsex() 
actor.setSex(" 女 ") ; 

void buildFace() 
actor.setFace(" 漂 亮 ") ， 

de void buildCostume() 

: actor.setCostume(" 白 裙 ")， 
a void buildHairstyle() 
actor.setHairstyle(" 披 肩 长 发 "); 


} 


// 恶 魔 角 色 建 造 器 : 具体 建造 者 
class DevilBuilder extends ActorBuilder 
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public void buildType() 
k actor.setType(" 和 恶魔 " ) ; 
void buildSex() 
actor.setSex(" 妖 ")，; 
de void buildFace() 
actor .setFace(" 天 陋 ")， 
a void buildCostume() 
: actor.setCostume(" 黑 衣 " ) ; 
void buildHairstyle() 
actor.setHairstyle(" 光 头 "); 
} 

} 


指挥 者 类 ActorController 定 义 了 construct0 方 法 ， 该 方法 拥有 一 个 抽象 建造 者 ActorBuilder 类 型 
的 参数 ， 在 该 方法 内 部 实现 了 游戏 角色 对 象 的 逐步 构建 ， 代 码 如 下 所 示 : 


// 游 戏 角色 创建 控制 器 : 指挥 者 
class ActorController 


// 逐 步 构 建 复杂 产品 对 象 

public Actor construct(ActorBuilder ab) 

{ 
Actor actor; 
ab .buildType(); 
ab .buildSex( ); 
ab .buildFace( ); 
ab .buildCostume( ); 
ab.buildHairstyle(); 
actor=ab.createActor(); 
return actor,; 


} 


为 了 提高 系统 的 灵活 性 和 可 扩展 性 ， 我 们 将 具体 建造 者 类 的 类 名 存储 在 配置 文件 中 ， 并 通过 
工具 类 XMLUtil 来 读 取 配 置 文件 并 反射 生成 对 象 ，XMLUtil 类 的 代码 如 下 所 示 : 


Import javax.xml.parsers.*,; 
Import org.w3c.dom,*， 

Import org.xml.sax.SAXException; 
import java.io.*,; 

class XMLUtil1 


{ 

// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 
public static Object getBean() 
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{ 
try 
{ 
// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuil 
DocumentBuilder builder = dFactory.newDocument 
Document doc; 
doc = builder.parse(new File("config.xml")); 
// 获 取 和 包含 类 名 的 文本 节点 
NodeList nl = doc.getElementsByTagName("classN: 
Node classNode=n]l1.item(0).getFirstchild(); 
String cName=classNode.getNodeValue(); 
// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName(cName); 
Object obj=c,newInstance( ); 
return obj 
} 
catch(Exception e) 
{ 
e.printStackTrace( ); 
return null; 
} 
} 


} 


配置 文件 config.xml 中 存储 了 具体 建造 者 类 的 类 名 ， 代 码 如 下 所 示 : 


<?xml1 version="1.0"?> 


<config> 


<className>AngelBuilder</className> 


</config> 


编写 如 下 容 户 端 测试 代码 : 


class Client 


{ 


public static void main(String args[]) 


{ 


ActorBuilder ab; // 针 对 抽象 建造 者 编程 


ab = 


(ActorBuilder)XMLUtil.getBean(); // 反 射 生 成 具体 建造 


ActorController ac = new ActorController(); 
Actor actor; 


actor 


String 


System. 
System. 
System. 
Systenm. 
.OUt .println(" 发 型 :" 


System 
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ac.construct(ab); // 通 过 指挥 者 创建 完整 的 建造 者 对 象 


type = actor.getType(); 
out ,println(type + "的 外 观 : ")， 
out ,println(" 性 别 :" + actor.getSex()); 
out .println(" 面 容 :" + actor.getFace()); 
out .println(" 服 装 :" + actor.getCostume()); 
+ actor.getHairstyle( )); 
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编译 并 运行 程序 ， 输 出 结果 如 下 : 


天 使 的 外 观 : 
性 别 : 女 

面容 : 漂亮 
服装 : 白 裙 
发 型 : 披肩 长 发 


在 建造 者 模式 中 ， 客 户 端 只 需 实 例 化 指挥 者 类 ， 指 挥 者 类 针对 抽象 建造 者 编程 ， 客 户 端 根据 
需要 传 入 具体 的 建造 者 类 型 ， 指 挥 者 将 指导 具体 建造 者 一 步 一 步 构 造 一 个 完整 的 产品 (逐步 
调用 具体 建造 者 的 buildX() 方 法 ) ， 相 同 的 构造 过 程 可 以 创建 完全 不 同 的 产品 。 在 游戏 角色 实 
例 中 ， 如 果 需 要 更 换 角 色 ， 只 需要 修改 配置 文件 ， 更 换 具 体 角 色 建 造 者 类 即 可 ; 如 果 需 要 增 
加 新 角色 ， 可 以 增加 一 个 新 的 具体 角色 建造 者 类 作为 抽象 角色 建造 者 的 子 类 ， 再 修改 配置 文 
件 即 可 ， 原 有 代码 无 须 修 改 ， 完 全 符合 “ 开 闭 原则 ”。 
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复杂 对 象 的 组 装 与 创建 一 一 建造 者 模式 (三) 
复杂 对 象 的 组 装 与 创建 一 一 建造 者 模式 (三) 


8.4 关于 Director 的 进一步 讨论 


指挥 者 类 Director 在 建造 者 模式 中 扮演 非常 重要 的 作用 ， 简 单 的 Director 类 用 于 指导 具体 建造 者 
如 何 构 建 产 品 ， 它 按 一 定 次 序 调用 Builder 的 buildPartX() 方 法 ， 控 制 调用 的 先后 次 序 ， 并 向 客 
户 端 返回 一 个 完整 的 产品 对 象 。 下 面 我 们 讨论 几 种 Director 的 高 级 应 用 方式 : 


1. 省 略 Director 


在 有 些 情况 下 ， 为 了 简化 系统 结构 ， 可 以 将 Director 和 抽象 建造 者 Builder 进 行 合并 ， 在 Builder 
中 提供 逐步 构建 复杂 产品 对 象 的 construct() 方 法 。 由 于 Builder 类 通常 为 抽象 类 ， 因 此 可 以 将 
construct() 方 法 定 义 为 静态 (static) 方 法 。 如 果 将 游戏 角色 设计 中 的 指挥 者 类 ActorController 省 
略 ，ActorBuilder 类 的 代码 修改 如 下 : 


abstract class ActorBuilder 


{ 


protected static Actor actor = new Actor(); 


public abstract void buildType(); 
public abstract void buildSex(); 
public abstract void buildFace(); 
public abstract void buildcostume( ); 
public abstract void buildHairstyle(); 


public static Actor construct(ActorBuilder ab) 
{ 

ab .buildType( ); 

ab .buildSex( ); 

ab .buildFace( ); 

ab .buildCostume( ); 

ab.buildHairstyle(); 

return actor; 


} 
对 应 的 客户 端 代码 也 将 发 生 修改 ， 其 代码 片段 如 下 所 示 : 


ActorBuilder ab; 
ab = (ActorBuilder)XMLUtil.getBean(); 


Actor actor; 
actor = ActorBuilder.construct(ab); 


除 此 之 外 ， 还 有 一 种 更 简单 的 处 理 方法 ， 可 以 将 construct() 方 法 的 参数 去 挤 ， 直 接 在 construct() 
方法 中 调用 buildPartX() 方 法 ， 代 码 如 下 所 示 : 
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abstract class ActorBuilder 


{ 


protected Actor actor = new Actor(); 


public abstract void buildType(); 
public abstract void buildSex( ) ， 
public abstract void buildFace(); 
public abstract void buildCostume( ); 
public abstract void buildHairstyle(); 


public Actor construct() 

{ 
this.buildType( ); 
this.buildSex(); 
this.buildFace( ); 
this.buildCostume( ); 
this.buildHairstyle(); 
return actor; 


} 
客户 端 代码 代码 片段 如 下 所 示 : 


ActorBuilder ab; 
ab = (ActorBuilder)XMLUtil.getBean(); 


Actor actor; 
actor = ab.construct(); 


此 时 ，construct() 方 法 定义 了 其 他 buildPartX() 方 法 调用 的 次 序 ， 为 其 他 方法 的 执行 提供 了 一 个 
流程 模板 ， 这 与 我 们 在 后 面 要 学 习 的 模板 方法 模式 非常 类 似 。 


以 上 两 种 对 Director 类 的 省 略 方 式 都 不 影响 系统 的 灵活 性 和 可 扩展 性 ， 同 时 还 简化 了 系统 结 
构 ， 但 加 重 了 抽象 建造 者 类 的 职责 ， 如 果 construct() 方 法 较为 复杂 ， 待 构建 产品 的 组 成 部 分 较 
多 ， 建 议 还 是 将 construct() 方 法 单独 封装 在 Director 中 ， 这 样 做 更 符合 “单一 职责 原则 ”。 


2. 钧 子 方法 的 引入 


建造 者 模式 除了 逐步 构建 一 个 复杂 产品 对 象 外 ， 还 可 以 通过 Director 类 来 更 加 精细 地 控制 产品 
的 创建 过 程 ， 例 如 增加 一 类 称 之 为 钩子 方法 (HookMethod) 的 特殊 方法 来 控制 是 否 对 某 个 
buildPartX() 的 调用 。 


钓 子 方法 的 返回 类 型 通常 为 boolean 类 型 ， 方 法 名 一 般 为 IsXXX()， 钓 子 方法 定义 在 抽象 建造 者 
类 中 。 例 如 我 们 可 以 在 游戏 角色 的 抽象 建造 者 类 ActorBuilder 中 定义 一 个 方法 isBareheaded() ， 
用 于 判断 某 个 角色 是 否 为 “光头 (Bareheaded)”， 在 ActorBuilder 为 之 提供 一 个 默认 实现 ， 其 返回 
值 为 false， 代 码 如 下 所 示 : 


abstract class ActorBuilder 


. 


protected Actor actor = new Actor(); 


public abstract void buildType(); 
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public abstract void buildSex(); 
public abstract void buildFace(); 
public abstract void buildcostume( ); 
public abstract void buildHairstyle(); 


// 钧 子 方法 
public boolean isBareheaded() 
{ 
return false; 
} 
public Actor createActor() 
{ 
return actor; 
} 


} 


如 果 某 个 角色 无 须 构建 头发 部 件 ， 例 如 “恶魔 (DeviD)”， 则 对 应 的 具体 建造 器 DevilBuilder 将 履 
盖 isBareheaded() 方 法 ， 并 将 返回 值 改 为 ttue， 代 码 如 下 所 示 : 


class DevilBuilder extends ActorBuilder 


public void buildType() 
l actor,setType(" 和 恶魔 " ) 
void buildSex() 
actor.setSex(" 妖 ")， 
de void buildFace() 
actor.setFace(" 天 陋 ")， 
ee void buildCostume() 
actor.setCostume(" 黑 衣 " ) ; 
de void buildHairstyle() 
actor.setHairstyle(" 光 头 ")，; 

人 

public boolean isBareheaded() 
: return true ， 
} 

} 


此 时 ， 指 挥 者 类 ActorController 的 代码 修改 如 下 : 


class ActorController 


t 
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Actor actor,; 
ab .buildType( ); 
ab .buildSex(); 
ab .buildFace( ); 
ab .buildCostume( ); 
// 通 过 钧 子 方法 来 控制 产品 的 构建 
if(!'ab.isBareheaded()) 
{ 


} 


actor=ab.createActor(); 
return actor; 


ab. buildHairstyle(); 


} 


当 在 客户 端 代 码 中 指定 具体 建造 者 类 型 并 通过 指挥 者 来 实现 产品 的 逐步 构建 时 ， 将 调用 钧 子 
方法 isBareheaded() 来 判断 游戏 角色 是 否 有 头发 ， 如 果 isBareheaded() 方 法 返回 true， 即 没有 头 
发 ， 则 跳 过 构建 发 型 的 方法 buildHairstyle() ; 否则 将 执行 buildHairstyle() 方 法 。 通 过 引入 钓 子 方 
法 ， 我 们 可 以 在 Director 中 对 复杂 产品 的 构建 进行 精细 的 控制 ， 不 仅 指定 buildPartX() 方 法 的 执 
行 顺 序 ， 还 可 以 控制 是 否 需要 执行 某 个 buildPartX() 方 法 。 

8.5 建造 者 模式 总 结 

建造 者 模式 的 核心 在 于 如 何 一 步 步 构建 一 个 包含 多 个 组 成 部 件 的 完整 对 象 ， 使 用 相同 的 构建 
过 程 构建 不 同 的 产品 ， 在 软件 开发 中 ， 如 果 我 们 需要 创建 复杂 对 象 并 希望 系统 具备 很 好 的 灵 
活性 和 可 扩展 性 可 以 考虑 使 用 建造 者 模式 。 

1. 主 要 优点 

建造 者 模式 的 主要 优点 如 下 : 


(1) 在 建造 者 模式 中 ， 客 户 端 不 必 知 道 产品 内 部 组 成 的 细节 ， 将 产品 本 身 与 产品 的 创建 过 程 解 
耦 ， 使 得 相同 的 创建 过 程 可 以 创建 不 同 的 产品 对 象 。 


(2) 每 一 个 具体 建造 者 都 相对 独立 ， 而 与 其 他 的 具体 建造 者 无 关 ， 因 此 可 以 很 方便 地 替换 具体 
建造 者 或 增加 新 的 具体 建造 者 ， 用 户 使 用 不 同 的 具体 建造 者 即 可 得 到 不 同 的 产品 对 象 。 由 于 
指挥 者 类 针对 抽象 建造 者 编程 ， 增 加 新 的 具体 建造 者 无 须 修改 原 有 类 库 的 代码 ， 系 统 扩展 方 
便 ， 符 合 * 开 闭 原则 ” 


(3) 可 以 更 加 精细 地 控制 产品 的 创建 过 程 。 将 复杂 产品 的 创建 步骤 分 解 在 不 同 的 方法 中 ， 使 得 
创建 过 程 更 加 清晰 ， 也 更 方便 使 用 程序 来 控制 创建 过 程 。 


2. 主 要 缺点 

建造 者 模式 的 主要 缺点 如 下 : 

(1) 建造 者 模式 所 创建 的 产品 一 般 具有 较 多 的 共同 点 ， 其 组 成 部 分 相似 ， 如 果 产 品 之 间 的 差异 
性 很 大 ， 例 如 很 多 组 成 部 分 都 不 相同 ， 不 适合 使 用 建造 者 模式 ， 因 此 其 使 用 范围 受到 一 定 的 
限制 。 


(2) 如 果 产 品 的 内 部 变化 复杂 ， 可 能 会 导致 需要 定义 很 多 具体 建造 者 类 来 实现 这 种 变化 ， 导 致 
系统 变 得 很 庞大 ， 增 加 系统 的 理解 难度 和 运行 成 本 。 


3. 适 用 场景 
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在 以 下 情况 下 可 以 考虑 使 用 建造 者 模式 : 
(1) 需要 生成 的 产品 对 象 有 复杂 的 内 部 结构 ， 这 些 产品 对 象 通常 包含 多 个 成 员 属 性 。 
(2) 需要 生成 的 产品 对 象 的 属性 相互 依赖 ， 需 要 指定 其 生成 顺序 。 


(3) 对 象 的 创建 过 程 独立 于 创建 该 对 象 的 类 。 在 建造 者 模式 中 通过 引入 了 指挥 者 类 ， 将 创建 过 
程 封装 在 指挥 者 关中 ， 而 不 在 建造 者 类 和 客户 类 中 。 


(4) 隔离 复杂 对 象 的 创建 和 使 用 ， 并 使 得 相同 的 创建 过 程 可 以 创建 不 同 的 产品 。 

练习 

Sunny 软 件 公司 欲 开 发 一 个 视频 播放 软件 ， 为 了 给 用 户 使 用 提供 方便 ， 该 播放 软件 提供 多 
种 界面 显示 模式 ， 如 完整 模式 、 精 简 模式 、 记 忆 模 式 、 网 络 模式 等 。 在 不 同 的 显示 模式 
下 主 界面 的 组 成 元 素 有 所 差异 ， 如 在 完整 模式 下 将 显示 菜单 、 播 放 列 表 、 主 窗口 、 控 制 


条 等 ， 在 精简 模式 下 只 显示 主 窗口 和 控制 条 ， 而 在 记忆 模式 下 将 显示 主 窗口 、 控 制 条 、 
收藏 列表 等 。 尝 试 使 用 建造 者 模式 设计 该 软件 。 
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我 的 笔记 本 电脑 的 工作 电压 是 20V， 而 我 国 的 家 庭 用 电 是 220V， 如 何 让 20V 的 笔记 本 电脑 能 够 
在 220V 的 电压 下 工作 ? 答案 是 引入 一 个 电源 适配器 (AC Adapter)， 俗 称 充电 器 或 变压器 ， 有 了 
这 个 电源 适配器 ， 生 活用 电 和 笔记 本 电脑 即 可 兼容 ， 如 图 9-1 所 示 : 


电源 适配器 





图 9-1 电源 适配器 示意 图 


在 软件 开发 中 ， 有 时 也 存在 类 似 这 种 不 兼容 的 情况 ， 我 们 也 可 以 像 引入 一 个 电源 适配器 一 样 
引入 一 个 称 之 为 适配器 的 角色 来 协调 这 些 存在 不 兼容 的 结构 ， 这 种 设计 方案 即 为 适配器 模 
式 。 


9.1 没有 源码 的 算法 库 


Sunny 软 件 公司 在 很 久 以 前 曾 开 发 了 一 个 算法 库 ， 里 面包 含 了 一 些 常用 的 算法 ， 例 如 排序 
算法 和 查找 算法 ， 在 进行 各 类 软件 开发 时 经 常 需要 重用 该 算法 库 中 的 算法 。 在 为 某 学 校 
开发 教务 管理 系统 时 ， 开 发 人 员 发 现 需 要 对 学 生成 绩 进 行 排序 和 查找 ， 该 系统 的 设计 人 
员 已 经 开发 了 一 个 成 绩 操 作 接 口 ScoreOperation， 在 该 接口 中 声明 了 排序 方法 sort(int[]) 和 
查找 方法 search(int[], inb， 为 了 提高 排序 和 查找 的 效率 ， 开 发 人 员 决 定 重 用 工法 库 中 的 快 
速 排序 算法 类 QuickSort 和 二 分 查找 算法 类 BinarySearch， 其 中 QuickSort 的 quickSort(int[]) 方 
法 实现 了 快速 排序 ，BinarySearch 的 binarySearch (int[], int) 方 法 实现 了 二 分 查找 。 
由 于 某 些 原因 ， 现 在 Sunny 公 司 开 发 人 员 已 经 找 不 到 该 算法 库 的 源 代码 ， 无 法 直接 通过 复制 和 
粘贴 操作 来 重用 其 中 的 代码 ; 部 分 开发 人 员 已 经 针对 ScoreOperation 接 口 编程 ， 如 果 再 要 求 对 
该 接口 进行 修改 或 要 求 大 家 直接 使 用 QuickSort 类 和 BinarySearch 类 将 导致 大 量 代码 需要 修改 。 
Sunny 软 件 公司 开发 人 员 面 对 这 个 没有 源码 的 算法 库 ， 遇 到 一 个 幸福 而 又 烦恼 的 问题 : 如 何在 
既 不 修改 现 有 接口 又 不 需要 任何 算法 库 代 码 的 基础 上 能 够 实现 算法 库 的 重用 ? 
通过 分 析 ， 我 们 不 难得 知 ， 现 在 Sunny 软 件 公司 面 对 的 问题 有 点 类 似 本 章 最 开始 所 提 到 的 电压 
问题 ， 成 绩 操 作 接口 ScoreOperation 好 比 只 支持 20V 电 压 的 笔记 本 ， 而 算法 库 好 比 220V 的 家 庭 
用 电 ， 这 两 部 分 都 没有 办 法 再 进行 修改 ， 而 且 它 们 原本 是 两 个 完全 不 相关 的 结构 ， 如 图 9-2 所 
示 : 
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不 兼容 结构 的 协调 适配器 模式 (一 ) 





教务 管理 系统 











BinarySearch 





图 9-2 需 协 调 的 两 个 系统 的 结构 示意 图 


现在 我 们 需要 ScoreOperation 接 口 能 够 和 已 有 算法 库 一 起 工作 ， 让 它们 在 同一 个 系统 中 能 够 兼 
容 ， 最 好 的 实现 方法 是 增加 一 个 类 似 电 源 适 配器 一 样 的 适配器 角色 ， 通 过 适配器 来 协调 这 两 
个 原本 不 兼容 的 结构 。 如 何在 软件 开发 中 设计 和 实现 适配器 是 本 章 我 们 将 要 解决 的 核心 问 
题 ， 下 面 就 让 我 们 正式 开始 学 习 这 种 用 于 解决 不 兼容 结构 问题 的 适配器 模式 。 


9.2 适配器 模式 概述 


与 电源 适配器 相似 ， 在 适配器 模式 中 引入 了 一 个 被 称 为 适配器 (Adapter) 的 包装 类 ， 而 它 所 包装 
的 对 象 称 为 适 配 者 (Adaptee])， 即 被 适 配 的 类 。 适 配器 的 实现 就 是 把 客户 类 的 请 求 转 化 为 对 适 
配 者 的 相应 接口 的 调用 。 也 就 是 说 : 当 客 户 类 调用 适配器 的 方法 时 ， 在 适配器 类 的 内 部 将 调 
用 适 配 者 类 的 方法 ， 而 这 个 过 程 对 客户 类 是 透明 的 ， 客 户 类 并 不 直接 访问 适 配 者 类 。 因 此 ， 
适配器 让 那些 由 于 接口 不 兼容 而 不 能 交互 的 类 可 以 一 起 工作 。 


适配器 模式 可 以 将 一 个 类 的 接口 和 另 一 个 类 的 接口 匹配 起 来 ， 而 无 须 修 改 原 来 的 适 配 者 接口 
和 抽象 目标 类 接口 。 适 配器 模式 定义 如 下 : 


适配器 模式 (Adapter Pattern) : 将 一 个 接口 转换 成 客户 希望 的 另 一 个 接口 ， 使 接口 不 兼容 的 那 
些 类 可 以 一 起 工作 ， 其 别名 为 包装 器 (Wrapper)。 适 配器 模式 既 可 以 作为 类 结构 型 模式 ， 也 可 
以 作为 对 象 结构 型 模式 。 


【 注 : 在 适配器 模式 定义 中 所 提 及 的 接口 是 指 广义 的 接口 ， 它 可 以 表示 一 个 方法 或 者 方法 的 
集合 。]】 


在 适配器 模式 中 ， 我 们 通过 增加 一 个 新 的 适配器 类 来 解决 接口 不 兼容 的 问题 ， 使 得 原本 没有 
任何 关系 的 类 可 以 协同 工作 。 根 据 适配器 类 与 适 配 者 类 的 关系 不 同 ， 适 配器 模式 可 分 为 对 销 
适配器 和 类 适配器 两 种 ， 在 对 象 适配器 模式 中 ， 适 配器 与 适 配 者 之 间 是 关联 关系 ; 在 类 适 配 
器 模式 中 ， 适 配器 与 适 配 者 之 间 是 继承 (或 实现 ) 关系 。 在 实际 开发 中 ， 对 象 适 配器 的 使 用 
频率 更 高 ， 对 象 适配器 模式 结构 如 图 9-3 所 示 : 
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Adaptee 








+ SpecificRequest () 


Adapter 


adaptee 














二 request () 





adaptee.specificRequest(); | 





图 9-3 对 象 适 配器 模式 结构 图 
在 对 象 适 配器 模式 结构 图 中 包含 如 下 几 个 角色 : 


e@ Target (目标 抽象 类 ) : 目标 抽象 类 定义 客户 所 需 接口 ， 可 以 是 一 个 抽象 类 或 接口 ， 也 可 以 
是 具体 类 。 


e@ Adapter ( 适 配 器 类 ) : 适配器 可 以 调用 另 一 个 接口 ， We 器 ， 对 Adaptee 和 Target 进 
行 适 配 ， 适 配器 类 是 适配器 模式 的 核心 ， 在 对 象 适 配器 中 ， 它 通过 继承 Target 并 关联 一 个 
Adaptee 对 象 使 二 者 产生 联系 。 


e@ Adaptee ( 适 配 者 类 ) : 适 配 者 即 被 适 配 的 角色 ， 它 定 证 多 了 一 个 世 经 存在 的 接 吕 ， 这 个 接口 
需要 适 配 ， 适 配 者 类 一 上 是 一 个 具体 类， 包含 了 客户 而 望 使 用 的 业务 方法 ， 在 某 些 情况 下 可 
能 没有 适 配 者 类 的 源 代 码 。 


根据 对 象 适 配器 模式 结构 图 ， 在 对 象 适 配器 中 ， 客 户 端 需要 调用 request) 方 法 ， 而 适 配 者 类 

Adaptee 没 有 该 方法 ， 但 是 它 所 提供 的 specificRequest( 方 法 却 是 客户 端 所 需要 的 。 "为 了 使 客户 

端 能 够 使 用 适 配 者 类 ， 需 要 提供 一 个 包装 类 Adapter， 即 适配器 类 。 这 个 包装 类 包装 了 一 个 适 

配 者 的 实例 ， 从 而 将 客户 端 与 适 配 者 衔接 起 来 ， 在 适配器 的 vequest 中 方法 中 调用 这 配 者 的 

Speci Rone 因为 适配器 类 与 适 配 者 类 是 关联 关系 (也 可 称 之 为 委派 关系 ) ， 所 以 
这 种 适配器 模式 称 为 对 象 适 配器 模式 。 典 型 的 对 象 适 配器 代码 如 下 所 示 : 


class Adapter extends Target { 
private Adaptee adaptee; // 维 持 一 个 对 适 配 者 对 象 的 引用 


public Adapter(Adaptee adaptee) { 
this,adaptee=adaptee 
} 


public void request() { 
adaptee.specificRequest(); // 转 发 调用 
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从 


在 对 象 适配器 中 ， 一 个 适配器 能 否 适 配 多 个 适 配 者 ? 如 果 能 ， 应 该 如 何 实现 ? 如果 不 
能 ， 请 说 明 原 因 ? 
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不 兼容 结构 的 协调 一 适 
不 兼容 结构 的 协调 一 适 


9.3 完整 解决 方案 


Sunny 软 件 公司 开发 人 员 决 定 使 用 适配器 模式 来 重用 算法 库 中 的 算法 ， 其 基本 结构 如 图 9-4 所 


示 









因 ScoreOperation 
-一 + sort (int array[]) :int QuickSort 
+ search (int arrayl], int key) : int | °° 一 
人 


+ quickSort (int array[]) : int 
+ Sort (int array[], int p, int r) :void 
+ partition (int a[], int p, int r) :int 

+ swap (int al], int i, int j) : void 








OperationAdapter 
- Sortobj :QuickSort 
- SearchObj : BinarySearch 
+ OperationAdapter () 
+ sort (int array[]) : int[] 
+ search (int array[], int key) : int 



















BinarySearch 
+ binarySearch (int array[], int key) : int 


图 9-4 算法 库 重 用 结构 图 


在 图 9-4 中 ，ScoreOperation 接 口 充当 抽象 目标 ，QuickSort 和 BinarySearch 类 充当 适 配 者 ， 
OperationAdapter 充 当 适 配器 。 完 整 代码 如 下 所 示 : 


// 抽 象 成 绩 操 作 类 : 目标 接口 
Interface Scoreoperation { 

public int[] sort(int array[])， // 成 绩 排 序 

public int search(int array[],int key); // 成 绩 查找 
} 


// 快 速 排序 类 : 适 配 者 
class QUuickSort { 
public int[] quickSort(int array[]) { 
sort(array,0,array.length-1); 
return array; 


} 
public void sort(int array[]j,int p, int r) { 
int q=0; 
if(p<r) f{ 
dq=partition(array,p,r); 
sort(array,p,dq-1); 
sort(array,dqdq+1,r); 
} 
} 
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public int partition(int[] a, int p, int r) { 
int x=al[r]; 
int j=p-1; 
for (int i=p;i<=r-1;i++) { 
if (a[i]<=x) { 
j++; 
swap(a, j,i); 


} 


swap(a,j+1,r); 
return j+1; 


} 


public void swap(int[] a, int i, int j) { 
int t = al[lil]; 
a[ij = a[j]; 
a[lj] = t; 


} 


// 二 分 查找 类 : 适 配 者 
class BinarySearch { 
public int binarySearch(int array[],int key) { 
int low = 0; 
int high = array.length -1; 
while(low <= high) { 
int mid = (low + high) / 2; 
int midVal = array[mid]; 
if(midVal < key) { 
low = mid +1; 


} 
else if (midVal > key) { 
high = mid -1; 


} 
else { 

return 1; // 找 到 元 素 返 回 1 
} 

} 

return -1; // 未 找到 元 素 返 回 -1 

} 

} 


// 操 作 适 配器 : 适配器 
class OperationAdapter implements ScoreOperation { 
private QuickSort sort0bj; // 定 义 适 配 者 QuickSort 对 象 
private BinarySearch search0bj; // 定 义 适 配 者 BinarySearch 对 象 


public OperationAdapter() { 


Sortobj = new QuickSort(); 
Searchobj = new BinarySearch( ); 
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public int[] sort(int array[]) { 
return sort0bj.quickSort(array); // 调 用 适 配 者 类 QuickSort 的 排序 方法 
} 


public int search(int array[],int key) { 
return search0bj .binarySearch(array,Key); // 调 用 适 配 者 类 BinarySearch 的 3 
} 
} 


为 了 让 系统 具备 良好 的 灵活 性 和 可 扩展 性 ， 我 们 引入 了 工具 类 XMLUtil 和 配置 文件 ， 其 中 ， 
XMLUtil 


类 的 代码 如 下 所 示 : 


Import javax.xml.parsers.*,; 

import org.w3c.dom,*， 

Import org.xml.sax.SAXException; 

import java.io.*,; 

class XMLUtil1 { 

// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 

public static Object getBean( ) { 
try { 

// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory.newDocumentBuilder( ); 
Document doc; 
doc = builder.parse(new File("config.xml")); 


// 获 取 和 包含 类 名 的 文本 节点 

NodeList nl = doc.getElementsByTagName("className"); 
Node classNode=nl1.item(0).getFirstChild(); 

String cName=classNode.getNodeVvalue(); 


// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName(cName); 
Object obj=c.newInstance( ); 
return obj; 

} 

catch(Exception e) { 
e.printStackTrace( ); 
return null; 


} 
配置 文件 config.xml 中 存储 了 适配器 类 的 类 名 ， 代 码 如 下 所 示 : 


<?xml1 version="1.0"?> 

<config> 
<className>0perationAdapter</className> 

</config> 


编写 如 下 客户 端 测试 代码 : 
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class Client { 
public static void main(String args[]) { 
ScoreOperation operation; // 针 对 抽象 目标 接口 编程 
operation = (Score0peration)XMLUtil.getBean(); // 读 取 配 置 文件 ， 
int scores[] = {84,76,50,69,90,91,88,96}; // 定 义 成 绩 数 组 
int result[]; 
int score; 


System,out,println(" 成 绩 排序 结果 :"); 
result = operation.sort(scores); 


// 遍 历 输 出 成 绩 

for(int i : Scores) { 
System.out.print(i + ","); 

} 


System.out.println(); 


System.out.println(" 查 找 成 绩 90 : ") ， 

Score = operation.search(result, 90); 

if (score != -1) { 
System.out.println(" 找 到 成 绩 90。"); 


} 

else { 
System.out.printLn(" 没 有 找到 成 绩 99。" ) ; 

} 


System.out.println(" 查 找 成 绩 92 : ")， 
Score = operation.search(result, 92); 
if (score != -1) { 

System.out .printLn(" 找 到 成 绩 92。" ) ; 
} 


else { 
System.out.println(" 没 有 找到 成 绩 92 。")， 
} 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


成 绩 排 序 结果 : 
50,69,76,84,88,90, 91, 96, 
查找 成 绩 90 : 

找到 成 绩 90 。 

查找 成 绩 92 : 

没有 找到 成 绩 92。 


在 本 实例 中 使 用 了 对 象 适配器 模式 ， 同 时 引入 了 配置 文件 ， 将 适配器 类 的 类 名 存储 在 配置 文 
件 中 。 如 果 需 要 使 用 其 他 排序 算法 类 和 查找 算法 类 ， 可 以 增加 一 个 新 的 适配器 类 ， 使 用 新 的 
适配器 来 适 配 新 的 算法 ， 原 有 代码 无 须 修改 。 通 过 引入 配置 文件 和 反射 机 制 ， 可 以 在 不 修改 
客户 端 代 码 的 情况 下 使 用 新 的 适配器 ， 无 须 修改 源 代码 ， 符 合 “ 开 闭 原则 ”。 
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不 兼容 结构 的 协调 一 一 迁 百 
不 兼容 结构 的 协调 一 一 适配器 模式 (三 ) 


9.4 类 适配器 


除了 对 象 适 配器 模式 之 外 ， 适 配器 模式 还 有 一 种 形式 ， 那 就 是 类 适配器 模式 ， 类 适配器 模式 
和 对 象 适 配器 模式 最 大 的 区 别 在 于 适配器 和 适 配 者 之 间 的 关系 不 同 ， 对 象 适 配器 模式 中 适 配 
器 和 适 配 者 之 间 是 关联 关系 ， 而 类 适配器 模式 中 适配器 和 适 配 者 是 继承 关系 ， 类 适配器 模式 
结构 如 图 9-5 所 示 : 


~“ Target Adaptee 








~ Target | Adaptee | 
上 Se 
+ request () | 

人 


+ request () 
上 








四 国生 





十 request () 


2 ~、 
specificRequest(); 


图 9-5 类 适配器 模式 结构 图 


根据 类 适配器 模式 结构 图 ， 适 配器 类 实现 了 抽象 目标 类 接口 Target， 并 继承 了 适 配 者 类 ， 在 适 
配器 类 的 request() 方 法 中 调用 所 继承 的 适 配 者 类 的 specificRequest() 方 法 ， 实 现 了 适 配 。 


典型 的 类 适配器 代码 如 下 所 示 : 


class Adapter extends Adaptee implements Target { 
public void request() { 
SpecificRequest() ; 
} 


} 

由 于 Java、C# 等 语言 不 支持 多 重 类 继承 ， 因 此 类 适配器 的 使 用 受到 很 多 限制 ， 例 如 如 果 目 标 
抽象 类 Target 不 是 接口 ， 而 是 一 个 类 ， 就 无 法 使 用 类 适配器 ; 此 外 ， 如 果 适 配 者 Adapter 为 最 终 
(FinaD) 类 ， 也 无 法 使 用 类 适配器 。 在 Java 等 面向 对 象 编程 语言 中 ， 大 部 分 情况 下 我 们 使 用 的 是 
对 象 适配器 ， 类 适配器 较 少 使 用 。 

思考 
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在 类 适配器 中 ， 一 个 适配器 能 否 适 配 多 个 适 配 者 ? 如果 能 ， 应 该 如 何 实 现 ? 如 果 不 能 ， 
请 说 明 原 因 ? 
9.5 双向 适配器 
在 对 象 适 配器 的 使 用 过 程 中 ， 如 果 在 适配器 中 同时 包含 对 目标 类 和 适 配 者 类 的 引用 ， 适 配 者 
可 以 通过 它 调 用 目标 类 中 的 方法 ， 目 标 类 也 可 以 通过 它 调 用 适 配 者 类 中 的 方法 ， 那 么 该 适 配 
器 就 是 一 个 双向 适配器 ， 其 结构 示意 图 如 图 9-6 所 示 : 


Adaptee 
+ specificRequest () 
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9 
euest 0 


+ request () 
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target 


- adaptee : Adaptee 

- target :Target 

+ Adapter (Target target) 

+ Adapter (Adaptee adaptee) 
+ request () 

+ SpecificRequest () 


ConcreteTarget 





ConcreteAdaptee 





+ request () es 









+ specificRequest () 










adaptee .specificRequest(); | 
target.request(); 


图 9-6 双向 适配器 结构 示意 图 





双向 适配器 的 实现 较为 复杂 ， 其 典型 代码 如 下 所 示 : 
class Adapter Implements Target,Adaptee { 
// 同 时 维持 对 抽象 目标 类 和 适 配 者 的 引用 
private Target target,; 
private Adaptee adaptee; 


public Adapter(Target target) { 
this.target = target,; 
} 


public Adapter(Adaptee adaptee) { 
this.adaptee = adaptee; 
} 


public void request() { 
adaptee. specificRequest(); 
} 


public void specificRequest() { 
target.request(); 
} 


} 
在 实际 开发 中 ， 我 们 很 少 使 用 双向 适配器 。 
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适配器 模式 (四 ) 


适配器 模式 (四 ) 


不 兼容 结构 的 协调 
不 兼容 结构 的 协调 





缺 省 适配器 模式 是 适配器 模式 的 一 种 变 体 ， 其 应 用 也 较为 广泛 。 缺 省 适配器 模式 的 定义 如 


缺 省 适配器 模式 (Default Adapter Pattern) : 当 不 需要 实现 一 个 接口 所 提供 的 所 有 方法 时 ， 可 先 
设计 一 个 抽象 类 实现 该 接口 ， 并 为 接口 中 每 个 方法 提供 一 个 默认 实现 ( 空 方法 ) ， 那 么 该 抽 
象 类 的 子 类 可 以 选择 性 地 履 盖 父 类 的 某 些 方法 来 实现 需求 ， 它 适用 于 不 想 使 用 一 个 接口 中 的 
所 有 方法 的 情况 ， 又 称 为 单 接口 适配器 模式 。 


缺 省 适配器 模式 结构 如 图 9-7 所 示 : 


> Servicelnterface 


+ serviceMethod1 () : void 


+ serviceMethod2 () : void 
+ serviceMethod3 () : void 





AbstractServiceClass 
{abstract} 


+ serviceMethod1 () : void 

+ serviceMethod2 () : void 

+ serviceMethod3 () : void 
A 


ConcreteServiceClass 


+ serviceMethod1 () : void | 





图 9-7 缺 省 适配器 模式 结构 图 
在 缺 省 适配器 模式 中 ， 包 含 如 下 三 个 角色 : 


不 兼容 结构 的 协调 适配器 模式 (四) 





e@ ServiceInterface ( 适 配 者 接口 ) : 它 是 一 个 接口 ， 通 常 在 该 接口 中 声明 了 大 量 的 方法 。 


e@ AbstractServiceClass ( 缺 省 适配器 类 ) : 它 是 缺 省 适配器 模式 的 核心 类 ， 使 用 空 方法 的 形式 
实现 了 在 ServiceInterface 接 口中 声明 的 方法 。 通 常 将 它 定 义 为 抽象 类 ， 因 为 对 它 进 行 实例 化 没 
有 任何 意义 。 


@ ConcreteServiceClass (具体 业务 类 ) : 它 是 缺 省 适配器 类 的 子 类 ， 在 没有 引入 适配器 之 前 ， 
它 需 要 实现 适 配 者 接口 ， 因 此 需要 实现 在 适 配 者 接口 中 定义 的 所 有 方法 ， 而 对 于 一 些 无 须 使 
用 的 方法 也 不 得 不 提供 空 实现 。 在 有 了 缺 省 适配器 之 后 ， 可 以 直接 继承 该 适配器 类 ， 根 据 需 
要 有 选择 性 地 履 盖 在 适配器 类 中 定义 的 方法 。 


在 JDK 类 库 的 事件 处 理 包 java.awt.event 中 广泛 使 用 了 缺 省 适配器 模式 ， 如 WindowAdapter、 
KeyAdapter、MouseAdapter 等 。 下 面 我 们 以 处 理 窗口 事件 为 例 来 进行 说 明 : 在 Java 语 言 中 ， 一 
般 我 们 可 以 使 用 两 种 方式 来 实现 窗口 事件 处 理 类 ， 一 种 是 通过 实现 WindowListener 接 口 ， 另 一 
种 是 通过 继承 WindowAdapter 适 配器 类 。 如 果 是 使 用 第 一 种 方式 ， 直 接 实 现 WindowListener 接 
口 ， 事 件 处 理 类 需要 实现 在 该 接口 中 定义 的 七 个 方法 ， 而 对 于 大 部 分 需求 可 能 只 需要 实现 一 
两 个 方法 ， 其 他 方法 都 无 须 实现 ， 但 由 于 语言 特性 我 们 不 得 不 为 其 他 方法 也 提供 一 个 简单 的 
实现 〈 通 常 是 空 实现 ) ， 这 给 使 用 带 来 了 麻烦 。 而 使 用 缺 省 适配器 模式 就 可 以 很 好 地 解决 这 
一 问题 ， 在 JDK 中 提供 了 一 个 适配器 类 WindowAdapter 来 实现 WindowListener 接 口 ， 该 适配器 
类 为 接口 中 的 每 一 个 方法 都 提供 了 一 个 空 实 现 ， 此 时 事件 处 理 类 可 以 继承 WindowAdapter 类 ， 
而 无 须 再 为 接口 中 的 每 个 方法 都 提供 实现 。 如 图 9-8 所 示 : 
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Eg WindowListener 


windowO pened (WindowEvent e) :void 
windowClosing (WindowEvent e) :void 
windowClosed (WindowEvent e) :void 


windowlconified (WindowEvent e) :void 
windowDeiconified (WindowEvent e) :void 
windowActivated (WindowEvent e) :void 
windowDeactivated (WindowEvent e) :void 





WindowAdapter 
{abstract} 


windowO pened (WindowEvent e) 
windowClosing (WindowEvent e) 
windowClosed (WindowEvent e) 
windowlconified (WindowEvent e) 
windowDeiconified (WindowEvent e) 
windowActivated (WindowEvent e) 
windowDeactivated (WindowEvent e) 
windowStateChanged (WindowEvent e) : 
windowGainedFocus (WindowEvente) : 
windowLostFocus (WindowEvent e) 





+ 
+ 
+ 
在 
+ 
将 
+ 
+ 
下 
王 


图 9-8 WindowListener 和 WindowAdapter 结 构 图 
9.7 适配器 模式 总 结 
适配器 模式 将 现 有 接口 转化 为 客户 类 所 期 望 的 接口 ， 实 现 了 对 现 有 类 的 复 用 ， 它 是 一 种 使 用 
频率 非常 高 的 设计 模式 ， 在 软件 开发 中 得 以 广泛 应 用 ， 在 Spring 等 开源 框架 、 驱 动 程序 设计 
(如 JDBC 中 的 数据 库 驱 动 程序 ) 中 也 使 用 了 适配器 模式 。 
1. 主要 优点 
无 论 是 对 象 适 配器 模式 还 是 类 适配器 模式 都 具有 如 下 优点 : 


(1) 将 目标 类 和 适 配 者 类 解 耦 ， 通 过 引入 一 个 适配器 类 来 重用 现 有 的 适 配 者 类 ， 无 须 修改 原 有 
结构 。 


(2) 增加 了 类 的 透明 性 和 复 用 性 ， 将 具体 的 业务 实现 过 程 封装 在 适 配 者 类 中 ， 对 于 客户 端 类 而 
言 是 透明 的 ， 而 且 提高 了 适 配 者 的 复 用 性 ， 同 一 个 适 配 者 类 可 以 在 多 个 不 同 的 系统 中 复 用 。 


(3) 灵活 性 和 扩展 性 都 非常 好 ， 通 过 使 用 配置 文件 ， 可 以 很 方便 地 更 换 适 配器 ， 也 可 以 在 不 修 
改 原 有 代码 的 基础 上 增加 新 的 适配器 类 ， 完 全 符合 “ 开 闭 原则 ”。 
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具体 来 说 ， 类 适配器 模式 还 有 如 下 优点 


由 于 适配器 类 是 适 配 者 类 的 子 类 ， 因 此 可 以 在 适配器 类 中 置换 一 些 适 配 者 的 方法 ， 使 得 适 配 
器 的 灵活 性 更 强 。 


对 象 适配器 模式 还 有 如 下 优点 


(1) 一 个 对 象 适 配器 可 以 把 多 个 不 同 的 适 配 者 适 配 到 同一 个 目标 ; 
ee 由 于 适配器 和 适 配 者 之 问 是 关联 关系 ， 根 据 “ 里 氏 代 换 原 
则 ”， 适 配 者 的 子 类 适配器 进行 适 配 。 

1. 主要 缺点 


类 适配器 模式 的 缺点 如 下 : 


(1) > C# 等 不 支持 多 重 类 继承 的 语言 ， 一 次 最 多 只 能 适 配 一 个 适 配 者 类 ， 不 能 同时 适 
配 多 个 适 配 者 ; 


(2) 适 配 者 类 不 能 为 最 终 类 ， 如 在 Java 中 不 能 为 final 类 ，C# 中 不 能 为 sealed 类 ; 


(3) 在 Java、C# 等 语言 中 ， 类 适配器 模式 中 的 目标 抽象 类 只 能 为 接口 ， 不 能 为 类 ， 其 使 用 有 一 
定 的 局 限 性 。 


对 象 适配器 模式 的 缺点 如 下 : 
与 类 适配器 模式 相 比 ， 要 在 适配器 中 置换 适 配 者 类 的 某 些 方法 比较 麻烦 。 如 果 一 定 要 置换 掉 
适 配 者 类 的 一 个 或 多 个 方法 ， 可 以 先 做 一 个 适 配 者 类 的 子 类 ， 将 适 配 者 类 的 方法 置换 掉 ， 然 
后 再 把 适 配 者 类 的 子 类 当做 真正 的 适 配 者 进行 适 配 ， 实 现 过 程 较为 复杂 。 

适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 适配器 模式 : 


(1) 系统 需要 使 用 一 些 现 有 的 类 ， 而 这 些 类 的 接口 (如 方法 名 ) 不 符合 系统 的 需要 ， 甚 至 没有 
这 些 类 的 源 代码 。 


(2) 想 创建 一 个 可 以 重复 使 用 的 类 ， 用 于 与 一 些 彼此 之 间 没 有 太 大 关联 的 一 些 类 ， 包 括 一 些 可 
能 在 将 来 引进 的 类 一 起 工作 。 


练习 


Sunny 软 件 公 司 OA 系统 需要 提供 一 个 加 密 模 块 ， 将 用 户 机 密 信 息 (如 口令 、 邮 箱 等 ) 加 
密 之 后 再 存储 在 数据 库 中 ， 系 统 已 经 定义 好 了 数据 库 操 作 类 。 为 了 提高 开发 效率 ， 现 需 
要 重用 已 有 的 加 密 算 法 ， 这 些 算 法 封装 在 一 些 由 第 三 方 提供 的 类 中 ， 有 些 甚至 没有 源 代 
码 。 试 使 用 适配器 模式 设计 该 加 密 模 块 ， 实 现在 不 修改 现 有 类 的 基础 上 重用 第 三 方 加密 
方法 。 
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桥接 模式 -Bridge Pattern 
桥接 模式 -Bridge Pattern 


桥接 模式 -Bridge Pattern 【学习 难度 : 女友 妈 闪 交 ， 使 用 频率 : 友 龙 友 六 六 】 


e。 桥接 模式 -Bridge Pattern 
o 处 理 多 维度 变化 桥接 模式 (一 ) 
o 处 理 多 维度 变化 \ 
o 处 理 多 维度 变化 
o 处 理 多 维度 变化 
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处 理 多 维度 变化 一 一 桥接 模式 (一 ) 
处 理 多 维度 变化 一 一 桥接 模式 (一 ) 


在 正式 介绍 桥接 模式 之 前 ， 我 先 跟 大 家 谈 谈 两 种 常见 文具 的 区 别 ， 它 们 是 毛笔 和 蜡笔 。 假 如 
我 们 需要 大 中 小 3 种 型 号 的 画笔 ， 能 够 绘制 12 种 不 同 的 颜色 ， 如 果 使 用 蜡笔 ， 需 要 准备 3x12 = 
36 支 ， 但 如 果 使 用 毛笔 的 话 ， 只 需要 提供 3 种 型 号 的 毛笔 ， 外 加 12 个 颜料 盒 即 可 ， 涉 及 到 的 对 
象 个 数 仅 为 3+ 12 =15， 远 小 于 36， 却 能 实现 与 36 支 蜡笔 同样 的 功能 。 如 果 增 加 一 种 新 型 号 的 
画笔 ， 并 且 也 需要 具有 12 种 颜色 ， 对 应 的 蜡笔 需 增加 12 支 ， 而 毛笔 只 需 增 加 一 支 。 为 什么 会 
这 样 呢 ? 通过 分 析 我 们 可 以 得 知 : 在 蜡笔 中 ， 颜 色 和 型 号 两 个 不 同 的 变化 维度 〈 即 两 个 不 同 
的 变化 原因 ) 融合 在 一 起 ， 无 论 是 对 颜色 进行 扩展 还 是 对 型 号 进行 扩展 都 势必 会 影响 另 一 个 
维度 ; 但 在 毛笔 中 ， 颜 色 和 型 号 实现 了 分 离 ， 增 加 新 的 磊 色 或 者 型 号 对 另 一 方 都 没有 任何 影 
响 。 如 果 使 用 软件 工程 中 的 术语 ， 我 们 可 以 认为 在 蜡笔 中 颜色 和 型 号 之 间 存 在 较 强 的 耦合 
性 ， 而 毛笔 很 好 地 将 二 者 解 耦 ， 使 用 起 来 非常 灵活 ， 扩 展 也 更 为 方便 。 在 软件 开发 中 ， 我 们 
也 提供 了 一 种 设计 模式 来 处 理 与 画笔 类 似 的 具有 多 变化 维度 的 情况 ， 即 本 章 将 要 介绍 的 桥接 
模式 。 


10.1 跨 平 台 图 像 浏览 系统 


Sunny 软 件 公司 欲 开 发 一 个 跨 平 台 图 像 浏览 系统 ， 要 求 该 系统 能 够 显示 BMP、JPG、GIF、 
PNG 等 多 种 格式 的 文件 ， 并 且 能 够 在 Windows、Linux、Unix 等 多 个 操作 系统 上 运行 。 系 统 首 
先 将 各 种 格式 的 文件 解析 为 像素 矩阵 (Matrixz)， 然 后 将 像素 矩阵 显示 在 屏幕 上 ， 在 不 同 的 操作 
系统 中 可 以 调用 不 同 的 绘制 函数 来 绘制 像素 矩阵 。 系 统 需 具有 较 好 的 扩展 性 以 支持 新 的 文件 
格式 和 操作 系统 。 


Sunny 软 件 公司 的 开发 人 员 针 对 上 述 要 求 ， 提 出 了 一 个 初始 设计 方案 ， 其 基本 结构 如 图 10-1 所 


示 
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10-1 跨 平 台 图 像 浏览 器 系统 初始 结构 图 . 


在 图 10-1 的 初始 设计 方案 中 ， 使 用 了 一 种 多 层 继承 结构 ，Image 是 抽象 父 类 ， 而 每 一 种 类 型 的 
图 像 类 ， 如 BMPImage、JPGImage 等 作为 其 直接 子 类 ， 不 同 的 图 像 文件 格式 具有 不 同 的 解析 方 
法 ， 可 以 得 到 不 同 的 像素 矩阵 ; 由 于 每 一 种 图 像 又 需要 在 不 同 的 操作 系统 中 显示 ， 不 同 的 操 
作 系 统 在 屏幕 上 显示 像素 矩阵 有 所 差异 ， 因 此 需要 为 不 同 的 图 像 类 再 提供 一 组 在 不 同 操作 系 
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统 显示 的 子 类 ， 如 为 BMPImage 提 供 三 个 子 类 BMPWindowsImp、BMPLinuxImp 和 
BMPUnixImp， 分 别 用 于 在 Windows、Linux 和 Unix 三 个 不 同 的 操作 系统 下 显示 图 像 。 


我 们 现在 对 该 设计 方案 进行 分 析 ， 发 现存 在 如 下 两 个 主要 问题 : 
(1) 由 于 采用 了 多 层 继承 结构 ， 导 致 系统 中 类 的 个 数 急剧 增加 ， 图 10-1 中 ， 在 各 种 图 像 的 操作 


系统 实现 层 提 供 了 12 个 具体 类 ， 加 上 各 级 抽象 层 的 类 ， 系 统 中 类 的 总 个 数 达 到 了 17 个 ， 在 该 
设计 方案 中 ， 有 具体 层 的 类 的 个 数 = 所 支持 的 图 像 文件 格式 数 x 所 支持 的 操作 系统 数 。 


(2) 系 统 扩展 麻烦 ， 由 于 每 一 个 具体 类 既 包 含 图 像 文 件 格式 信息 ， 又 包含 操作 系统 信息 ， 因 此 
无 论 是 增加 新 的 图 像 文件 格式 还 是 增加 新 的 操作 系统 ， 都 需要 增加 大 量 的 具体 类 ， 例 如 在 图 
10-1 中 增加 一 种 新 的 图 像 文件 格式 TIF， 则 需要 增加 3 个 具体 类 来 实现 该 格式 图 像 在 3 种 不 同 操 
作 系 统 的 显示 ; 如 果 增 加 一 个 新 的 操作 系统 Mac OS， 为 了 在 该 操作 系统 下 能 够 显示 各 种 类 型 
的 图 像 ， 需 要 增加 4 个 具体 类 。 这 将 导致 系统 变 得 非常 庞大 ， 增 加 运行 和 维护 开销 。 


如 何 解决 这 两 个 问题 ?我们 通过 分 析 可 得 知 ， 该 系统 存在 两 个 独立 变化 的 维度 : 图 像 文件 格 
式 和 操作 系统 ， 如 图 10-2 所 示 : 


Windows 


Linux 


Unix 维度 刘 图 
像 文件 格式 





BMP JPG GIF PNG 
10-2 跨 平 台 图 像 浏览 器 中 存在 的 两 个 独立 变化 维度 示意 图 


在 图 10-2 中 ， 如 何 将 各 种 不 同类 型 的 图 像 文件 解析 为 像素 矩阵 与 图 像 文件 格式 本 身 相 关 ， 而 如 
何在 屏幕 上 显示 像素 矩阵 则 仅 与 操作 系统 相关 。 正 因为 图 10-1 所 示 结 构 将 这 两 种 职责 集中 在 一 
个 类 中 ， 导 致 系统 扩展 麻烦 ， 从 类 的 设计 角度 分 析 ， 具 体 类 BMPWindowsImp、BMPLinuxImp 
和 BMPUnixImp 等 违反 了 “单一 职责 原则 ”， 因 为 不 止 一 个 引起 它们 变化 的 原因 ， 它 们 将 图 像 文 
件 解析 和 像素 矩阵 显示 这 两 种 完全 不 同 的 职责 融合 在 一 起 ， 任 意 一 个 职责 发 生 改 变 都 需要 修 
改 它们 ， 系 统 扩 展 困 难 。 


如 何 改进 ? 我们 的 方案 是 将 图 像 文件 格式 (对 应 图 像 格 式 的 解析 ) 与 操作 系统 (对 应 像素 给 
阵 的 显示 ) 两 个 维度 分 离 ， 使 得 它们 可 以 独立 变化 ， 增 加 新 的 图 像 文件 格式 或 者 操作 系统 时 
都 对 另 一 个 维度 不 造成 任何 影响 。 看 到 这 里 ， 大 家 可 能 会 问 ， 到 底 如 何在 软件 中 实现 将 两 个 
维度 分 离 呢 ? 不 用 着 急 ， 本 章 我 将 为 大 家 详细 介绍 一 种 用 于 处 理 多 维度 变化 的 设计 模式 
桥接 模式 。 
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10.2 桥接 模式 概述 


桥接 模式 是 一 种 很 实用 的 结构 型 设计 模式 ， 如 果 软 件 系 统 中 某 个 类 存在 两 个 独立 变化 的 维 

度 ， 通 过 该 模式 可 以 将 这 两 个 维度 分 离 出 来 ， 使 两 者 可 以 独立 扩展 ， 让 系统 更 加 符合 “单一 职 
责 原则 ”。 与 多 层 继承 方案 不 同 ， 它 将 两 个 独立 变化 的 维度 设计 为 两 个 独立 的 继承 等 级 结构 ， 
并 且 在 抽象 层 建立 一 个 抽象 关联 ， 该 关联 关系 类 似 一 条 连接 两 个 独立 继承 结构 的 桥 ， 故 名 桥 
接 模 式 。 


桥接 模式 用 一 种 巧妙 的 方式 处 理 多 层 继 承 存在 的 问题 ， 用 抽象 关联 取代 了 传统 的 多 层 继承 ， 
将 类 之 间 的 静态 继承 关系 转换 为 动态 的 对 象 组 合 关系 ， 使 得 系统 更 加 灵活 ， 并 易于 扩展 ， 同 
时 有 效 控制 了 系统 中 类 的 个 数 。 桥 接 定义 如 下 : 


桥接 模式 (Bridge Pattern) : 将 抽象 部 分 与 它 的 实现 部 分 分 离 ， 使 它们 都 可 以 独立 地 变化 。 它 是 
一 种 对 象 结构 型 模式 ， 又 称 为 桥 体 (Handle and Body) 模 式 或 接口 (Interface) 模 式 。 


桥接 模式 的 结构 与 其 名 称 一 样 ， 存 在 一 条 连接 两 个 继承 等 级 结构 的 桥 ， 桥 接 模式 结构 如 图 10-3 
所 示 : 








“~ Implementor 
+ operationImpl () 
A 


Abstraction 
+ operation () 
八 Sy 
















ConcretelmplementorA ConcretelmplementorB 


+ operationImpl () | 






RefinedAbstraction 
+ operation () 





+ operationImpl () 


10-3 桥接 模式 结构 图 . 
在 桥接 模式 结构 图 中 包含 如 下 几 个 角色 : 





eAbstraction (抽象 类 ) : 用 于 定义 抽象 类 的 接口 ， 它 一 般 是 抽象 类 而 不 是 接口 ， 其 中 定义 了 
一 个 Implementor (实现 类 接口 ) 类 型 的 对 象 并 可 以 维护 该 对 象 ， 它 与 Implementor 之 间 具 有 关 
联 关系 ， 它 既 可 以 包含 抽象 业务 方法 ， 也 可 以 包含 具体 业务 方法 。 

eRefinedAbstraction (扩充 抽象 类 ) : 扩充 由 Abstraction 定 义 的 接口 ， 通 常情 况 下 它 不 再 是 抽 
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象 类 而 是 具体 类 ， 它 实现 了 在 Abstraction 中 声明 的 抽象 业务 方法 ， 在 RefinedAbstraction 中 可 以 
调用 在 Implementor 中 定义 的 业务 方法 。 


eImplementor (实现 类 接口 ) : 定义 实现 类 的 接口 ， 这 个 接口 不 一 定 要 与 Abstraction 的 接口 完 
全 一 致 ， 事 实 上 这 两 个 接口 可 以 完全 不 同 ， 一 般 而 言 ，Implementor 接 口 仅 提供 基本 操作 ， 而 

Abstraction 定 义 的 接口 可 能 会 做 更 多 更 复杂 的 操作 。Implementor 接 口 对 这 些 基本 操作 进行 了 上 声 
明 ， 而 具体 实现 交 给 其 子 类 。 通 过 关联 关系 ， 在 Abstraction 中 不 仅 拥 有 自己 的 方法 ， 还 可 以 调 
用 到 Implementor 中 定义 的 方法 ， 使 用 关联 关系 来 替代 继承 关系 。 


eConcreteImplementor (具体 实现 类 ) : 具体 实现 Implementor 接 口 ， 在 不 同 的 
ConcreteImplementor 中 提供 基本 操作 的 不 同 实 现 ， 在 程序 运行 时 ，ConcreteImplementor 对 象 将 
替换 其 父 类 对 象 ， 提 供给 抽象 类 具体 的 业务 操作 方法 。 


桥接 模式 是 一 个 非常 有 用 的 模式 ， 在 桥接 模式 中 体现 了 很 多 面向 对 象 设计 原则 的 思想 ， 包 
括 “ 单 一 职责 原则 ”、“ 开 闭 原则 ”»”、“ 合 成 复 用 原则 ”、“ 里 氏 代 换 原则 ”、“ 依 赖 倒转 原则 ”等 。 熟 
悉 桥接 模式 有 助 于 我 们 深入 理解 这 些 设计 原则 ， 也 有 助 于 我 们 形成 正确 的 设计 思想 和 培养 良 
好 的 设计 风格 。 


在 使 用 桥接 模式 时 ， 我 们 首先 应 该 识别 出 一 个 类 所 具有 的 两 个 独立 变化 的 维度 ， 将 它们 设计 
为 两 个 独立 的 继承 等 级 结构 ， 为 两 个 维度 都 提供 抽象 层 ， 并 建立 抽象 耦合 。 通 常情 况 下 ， 我 
们 将 具有 两 个 独立 变化 维度 的 类 的 一 些 普通 业务 方法 和 与 之 关系 最 密切 的 维度 设计 为 “抽象 

类 ”层次 结构 (抽象 部 分 ) ， 而 将 另 一 个 维度 设计 为 “实现 类 ”层次 结构 (实现 部 分 ) 。 例 如 : 

对 于 毛笔 而 言 ， 由 于 型 号 是 其 固有 的 维度 ， 因 此 可 以 设计 一 个 抽象 的 毛笔 类 ， 在 该 类 中 声明 

并 部 分 实现 毛笔 的 业务 方法 ， 而 将 各 种 型 号 的 毛笔 作为 其 子 类 ; 颜色 是 毛笔 的 另 一 个 维度 ， 

由 于 它 与 毛笔 之 间 存 在 一 种 “设置 ”的 关系 ， 因 此 我 们 可 以 提供 一 个 抽象 的 颜色 接口 ， 而 将 具体 
的 颜色 作为 实现 该 接口 的 子 类 。 在 此 ， 型 号 可 认为 是 毛笔 的 抽象 部 分 ， 而 颜色 是 毛笔 的 实现 
部 分 ， 结 构 示 意图 如 图 10-4 所 示 : 


毛笔 


+ 设置 颜色 (颜色 color) 


小 号 毛笔 
| 
+ 绘图 () 


下 | /其 他 代码 
color. 着 色 (); 
1// 其 他 代码 











10-4 毛笔 结构 示意 图 ， 


在 图 10-4 中 ， 如 果 需 要 增加 一 种 新 型 号 的 毛笔 ， 只 需 扩 展 左 侧 的 “抽象 部 分 ”， 增 加 一 个 新 的 扩 
充 抽象 类 ; 如 果 需 要 增加 一 种 新 的 颜色 ， 只 需 扩展 右 侧 的 “实现 部 分 ”， 增 加 一 个 新 的 具体 实现 
类 。 扩 展 非常 方便 ， 无 须 修改 已 有 代码 ， 且 不 会 导致 类 的 数目 增长 过 快 。 


在 具体 编码 实现 时 ， 由 于 在 桥接 模式 中 存在 两 个 独立 变化 的 维度 ， 为 了 使 两 者 之 间 耦 合 度 降 
低 ， 首 先 需 要 针对 两 个 不 同 的 维度 提取 抽象 类 和 实现 类 接口 ， 并 建立 一 个 抽象 关联 关系 。 对 
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于 “实现 部 分 ”维度 ， 典 型 的 实现 类 接口 代码 如 下 所 示 : 


interface Implementor { 
public void operationImpl1(); 
} 


在 实现 Implementor 接 口 的 子 类 中 实现 了 在 该 接口 中 声明 的 方法 ， 用 于 定义 与 该 维度 相对 应 的 
一 些 具体 方法 。 


对 于 另 一 “抽象 部 分 "维度 而 言 ， 其 典型 的 抽象 类 代码 如 下 所 示 : 


abstract class Abstraction { 
protected Implementor impl; // 定 义 实 现 类 接口 对 象 


public void setIimpl(Implementor impl) { 
this.impl=impl; 
} 


public abstract void operation(); // 声 明 抽象 业务 方法 
} 


在 抽象 类 Abstraction 中 定义 了 一 个 实现 类 接口 类 型 的 成 员 对 象 impl， 再 通过 注入 的 方式 给 该 对 
象 赋值 ， 一 般 将 该 对 象 的 可 见 性 定义 为 protected ， 以 便 在 其 子 类 中 访问 Implementor 的 方法 ， 其 
子 类 一 般 称 为 扩充 抽象 类 或 细 化 抽象 类 (RefinedAbstraction)， 典 型 的 RefinedAbstraction 类 代码 
如 下 所 示 : 


class RefinedAbstraction extends Abstraction { 
public void operation() { 
// 业 务 代码 
impl.operationImpl(); // 调 用 实现 类 的 方法 
// 业 务 代码 


} 

对 于 客户 端 而 言 ， 可 以 针对 两 个 维度 的 抽象 层 编程 ， 在 程序 运行 时 再 动态 确定 两 个 维度 的 子 
类 ， 动 态 组 合 对 象 ， 将 两 个 独立 变化 的 维度 完全 解 耘 ， 以 便 能 够 灵活 地 扩充 任 一 维度 而 对 另 
一 维度 不 造成 任何 影响 。 

思考 


如 果 系统 中 存在 两 个 以 上 的 变化 维度 ， 是 否 可 以 使 用 桥接 模式 进行 处 理 ? 如 果 可 以 ， 系 
统 该 如 何 设 计 ? 
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10.3 完整 解决 方案 
为 了 减少 所 需 生成 的 子 类 数目 ， 实 现 将 操作 系统 和 图 像 文 件 格式 两 个 维度 分 离 ， 使 它们 可 以 


独立 改变 ，Sunny 公 司 开发 人 员 使 用 桥接 模式 来 重 构 跨 平 台 图 像 浏览 系统 的 设计 ， 其 基本 结构 
如 图 10-5 所 示 : 





图 10-5 跨 平台 图 像 浏 览 系 统 结构 图 . 


在 图 10-5 中 ，Image 充 当 抽象 类 ， 其 子 类 JPGImage、PNGImage、BMPImage 和 GIFImage 充 当 扩 
充 抽象 类 ; ImageImp 充 当 实 现 类 接口 ， 其 子 类 WindowsImp、LinuxImp 和 UnixImp 充 当 具 体 实 
现 类 。 完 整 代码 如 下 所 示 : 
// 像 素 矩 阵 类 : 辅助 类 ， 各 种 格式 的 文件 最 终 都 被 转化 为 像素 矩阵 ， 不 同 的 操作 系统 提供 不 同 
class Matrix { 

// 此 处 代码 省 略 
} 


// 抽 象 图 像 类 : 抽象 类 
abstract class Image { 
protected ImageImp imp; 


public void SetImageImp(ImageImp imp) { 
this.imp = imp; 
} 
public abstract void parseFile(String fileName); 
} 
// 抽 象 操 作 系统 实现 类 : 实现 类 接口 
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interface ImageImp { 
public void doPaint(Matrix m); // 显 示 像 素 矩 阵 m 
} 


//Windows 操 作 系 统 实现 类 : 具体 实现 类 
class WindowsImp implements ImageImp { 
public void dopaint(Matrix m) { 
// 调 用 Windows 系 统 的 绘制 函数 绘制 像素 矩阵 
System.out.print(" 在 Windows 操 作 系 统 中 显示 图 像 : ")， 


} 


//Linux 操 作 系 统 实现 类 : 具体 实现 类 
class LinuxImp implements ImageImp { 
public void dopaint(Matrix m) { 
// 调 用 Linux 系 统 的 绘制 函数 绘制 像素 矩阵 
System,out,print(" 在 LinuX 操 作 系 统 中 显示 图 像 : ") ; 


} 


//Unix 操 作 系 统 实现 类 : 具体 实现 类 
class UnixImp implements ImageImp { 
public void dopaint(Matrix m) { 
// 调 用 Unix 系 统 的 绘制 函数 绘制 像素 矩阵 
System,out ,print(" 在 Unix 操 作 系统 中 显示 图 像 : " ) ; 


} 


//JPG 格 式 图 像 : 扩充 抽象 类 
class JPGImage extends Image { 
public void parseFile(String fileName) { 
// 模 拟 解 析 JPG 文 件 并 获得 一 个 像素 和 矩阵 对 象 m; 
Matrix m = new Matrix(); 
imp.doPpaint(m); 
System.out.println(fileName + "， 格 式 为 JPG。")， 


} 


//PNG 格 式 图 像 : 扩充 抽象 类 
class PNGImage extends Image { 
public void parseFile(String fileName) { 
// 模 拟 解 析 PNG 文 件 并 获得 一 个 像素 给 阵 对 象 m; 
Matrix m = new Matrix(); 
imp ,doPaint(m) ， 
System.out .printLn(fileName + "， 格 式 为 PNG。")， 


} 


//BMP 格 式 图 像 : 扩充 抽象 类 
class BMPImage extends Image { 
public void parseFile(String fileName) { 
// 模 拟 解 析 BMP 文 件 并 获得 一 个 像素 矩阵 对 象 m; 
Matrix m = new Matrix(); 


157 


处 理 多 维度 变化 


Imp ， 





桥接 模式 (三) 


doPaint(m); 


System.out.println(fileName + "， 格 式 为 BMP。")， 


} 


//GIF 格 式 图 像 : 扩充 抽象 类 
class GIFImage extends Image { 
public void parseFile(String fileName) { 
// 模 拟 解 析 GIF 文 件 并 获得 一 个 像素 矩阵 对 象 m; 
Matrix m = new Matrix(); 


imp. 


doPaint(m); 


System.out.println(fileName + "， 格 式 为 GIF。"); 


} 


为 了 让 系统 具有 更 好 的 灵活 性 和 可 扩展 性 ， 我 们 引入 了 配置 文件 ， 将 具体 扩充 抽象 类 和 具体 
实现 类 类 名 都 存储 在 配置 文件 中 ， 再 通过 反射 生成 对 象 ， 将 生成 的 具体 实现 类 对 象 注入 到 扩 


充 抽 象 类 对 象 中 


， 其中， 配置 文件 config.xml 的 代码 如 下 所 示 : 


<?xml1 version="1.0"?> 


<config> 


<!--RefinedAbstraction--> 
<className>JPGImage</className> 
<!--ConcreteImplementor--> 
<className>WindowsImp</className> 


</config> 


用 于 读 取 配置 文件 config.xml 并 反射 生成 对 象 的 XMLUti 类 的 代码 如 下 所 示 : 


import javax.xml.parsers.*,; 
import org.w3c.dom.*,; 
import org.xml.sax.SAXException; 


import java. 


i103 


public class XMLUtil { 
// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 
public static Object getBean(String args) { 
try { 


158 


// 创 建文 档 对 象 

DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory,newDocumentBuilder( ) ， 
Document doc; 

doc = builder.parse(new File("config.xml")); 

NodeList nl=null; 

Node classNode=null; 

String cName=null; 

nl = doc.getElementsByTagName ("className"); 


if(args.equals("image")) { 
// 获 取 第 一 个 包含 类 名 的 节点 ， 即 扩充 抽象 类 
classNode=nl1.item(0).getFirstchild(); 


} 


else if(args.equals("os")) { 
// 获 取 第 二 个 包含 类 名 的 节点 ， 即 具体 实现 类 
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classNode=nl1.item(1).getFirstchild(); 


cName=classNode.getNodeValue( ); 
// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName(cName); 
Object obj=c.newInstance( ); 
return obj; 


catch(Exception e) { 
e.printStackTrace( ); 
return null; 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 

Image image; 
ImageImp imp; 
image = (Image)XMLUtil.getBean("image"); 
imp = (ImageImp)XMLUtil.getBean("os"); 
image.setIimageImp(imp); 
image .parseFile(" 小 龙 女 ")， 


} 

编译 并 运行 程序 ， 输 出 结果 如 下 : 

在 Windows 操 作 系统 中 显示 图 像 : 小 龙 女 ， 格 式 为 JPG。 

如 果 需 要 更 换 图 像 文件 格式 或 者 更 换 操 作 系 统 ， 只 需 修 改 配 置 文件 即 可 ， 在 实际 使 用 时 ， 可 
以 通过 分 析 图 像 文件 格式 后 组 名 来 确定 具体 的 文件 格式 ， 在 程序 运行 时 获取 操作 系统 信息 来 
确定 操作 系统 类 型 ， 无 须 使 用 配置 文件 。 当 增加 新 的 图 像 文件 格式 或 者 操作 系统 时 ， 原 有 系 


统 无 须 做 任何 修改 ， 只 需 增加 一 个 对 应 的 扩充 抽象 类 或 具体 实现 类 即 可 ， 系 统 具有 较 好 的 可 
扩展 性 ， 完 全 符合 < 开 闭 原则 ”。 
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10.4 适配器 模式 与 桥接 模式 的 联 用 


一 ”桥接 模式 (四 ) 
一 一 桥接 模式 (四) 


在 软件 开发 中 ， 适 配器 模式 通常 可 以 与 桥接 模式 联合 使 用 。 适 配器 模式 可 以 解决 两 个 已 有 接 
口 间 不 兼容 问题 ， 在 这 种 情况 下 被 适 配 的 类 往往 是 一 个 黑人 金子， 有 时 候 我 们 不 想 也 不 能 改变 
这 个 被 适 配 的 类 ， 也 不 能 控制 其 扩展 。 适 配器 模式 通常 用 于 现 有 系统 与 第 三 方 产品 功能 的 集 


成 ， 采 用 增加 适配器 的 方式 将 第 三 方 类 
继承 或 类 继承 的 方式 来 对 系统 进行 扩展 。 


集成 到 系统 中 。 桥 接 模式 则 不 同 ， 用户 可 以 通过 接口 


桥接 模式 和 适配器 模式 用 于 设计 的 不 同 阶段 ， 桥 接 模式 用 于 系统 的 初步 设计 ， 对 于 存在 两 个 
独立 变化 维度 的 类 可 以 将 其 分 为 抽象 化 和 实现 化 两 个 角色 ， 使 它们 可 以 分 别 进 行 变 化 ; 而 在 
初步 设计 完成 之 后 ， 当 发 现 系统 与 已 有 类 无 法 协同 工作 时 ， 可 以 采用 适配器 模式 。 但 有 时 候 
在 设计 初期 也 需要 考虑 适配器 模式 ， 特 别 是 那些 涉及 到 大 量 第 三 方 应 用 接口 的 情况 。 


下 面 通 过 一 个 实例 来 说 明 适 配器 模式 和 桥接 模式 的 联合 使 用 : 


在 某 系统 的 报表 处 理 模块 中 ， 需 要 将 报表 显示 和 数据 采集 分 开 ， 系 统 可 以 有 多 种 报表 显示 方 
式 也 可 以 有 多 种 数据 采集 方式 ， 如 可 以 从 文本 文件 中 读 取 数据 ， 也 可 以 从 数据 库 中 读 取 数 

据 ， 还 可 以 从 Excel 文 件 中 获取 数据 。 如 果 需 要 从 Excel 文 件 中 获取 数据 ， 则 需要 调用 与 Excel 相 
关 的 API， 而 这 个 API 是 现 有 系统 所 不 具备 的 ， 该 API 由 厂商 提供 。 使 用 适配器 模式 和 桥接 模式 


设计 该 模块 。 


在 设计 过 程 中 ， 由 于 存在 报表 显示 和 数据 采集 两 个 独立 变化 的 维度 ， 因 此 可 以 使 用 桥接 模式 
进行 初步 设计 ; 为 了 使 用 Excel 相 关 的 API 来 进行 数据 采集 则 需要 使 用 适配器 模式 。 系 统 的 完整 
设计 中 需要 将 两 个 模式 联 用 ， 如 图 10-6 所 示 : 





桥接 模式 






适配器 模式 





Excel API 











具体 报表 显示 方式 1 












10-6 桥接 模式 与 适配器 模式 联 用 示意 图 ， 


10.5 桥接 模式 总 结 
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桥接 模式 是 设计 Java 虚 拟 机 和 实现 JDBC 等 驱动 程序 的 核心 模式 之 一 ， 应 用 较为 广泛 。 在 软件 
开发 中 如 果 一 个 类 或 一 个 系统 有 多 个 变化 维度 时 ， 都 可 以 尝试 使 用 桥接 模式 对 其 进行 设计 。 
桥接 模式 为 多 维度 变化 的 系统 提供 了 一 套 完整 的 解决 方案 ， 并且 降低 了 系统 的 复杂 度 。 1. 主 
要 优点 

桥接 模式 的 主要 优点 如 下 : 

(1) 分 离 抽 象 接口 及 其 实现 部 分 。 桥 接 模 式 使 用 “对 象 间 的 关联 关系 * 解 看 了 抽象 和 实现 之 间 
有 的 绑 定 关系 ， 使 得 抽象 和 实现 可 以 沿 着 各 自 的 维度 来 变化 。 所 谓 抽象 和 实现 沿 着 各 自 维度 
的 变化 ， 也 就 是 说 抽象 和 实现 不 再 在 同一 个 继承 层次 结构 中 ， 而 是 “ 子 类 化 > 它们， 使 它们 各 自 
都 具有 自己 的 子 类 ， 以 便 任何 组 合子 类 ， 从 而 获得 多 维度 组 合 对 象 。 

(2) 在 很 多 情况 下 ， 桥 接 模 式 可 以 取代 多 层 继 承 方案 ， 多 层 继 承 方案 违背 了 “单一 职责 原则 ”， 
复 用 性 较 差 ， 且 类 的 个 数 非常 多 ， 桥 接 模式 是 比 多 层 继承 方案 更 好 的 解决 方法 ， 它 极 大 减少 
了 子 类 的 个 数 。 


(3) 桥 接 模式 提高 了 系统 的 可 扩展 性 ， 在 两 个 变化 维度 中 任意 扩展 一 个 维度 ， 都 不 需要 修改 原 
有 系统 ， 符 合 < 开 闭 原则 ”。 


2. 主 要 缺点 
桥接 模式 的 主要 缺点 如 下 : 


(TD 桥接 模式 的 使 用 会 增加 系统 的 理解 与 设计 难度 ， 由 于 关联 关系 建立 在 抽象 层 ， 要 求 开发 者 
一 开始 就 针对 抽象 层 进 行 设计 与 编程 。 


(2) 桥 接 模式 要 求 正确 识别 出 系统 中 两 个 独立 变化 的 维度 ， 因 此 其 使 用 范围 具有 一 定 的 局 限 
性 ， 如 何 正确 识别 两 个 独立 维度 也 需要 一 定 的 经 验 积 累 。 


3. 适 用 场景 
在 以 下 情况 下 可 以 考虑 使 用 桥接 模式 : 


(如 果 一 个 系统 需要 在 抽象 化 和 具体 化 之 间 增 加 更 多 的 灵活 性 ， 避 免 在 两 个 层次 之 间 建 立 静 
态 的 继承 关系 ， 通 过 桥接 模式 可 以 使 它们 在 抽象 层 建立 一 个 关联 关系 。 

(2)“ 抽 象 部 分 ”和 “实现 部 分 ?可 以 以 继承 的 方式 独立 扩展 而 互 不 影响 ， 在 程序 运行 时 可 以 动态 
将 一 个 抽象 化 子 类 的 对 象 和 一 个 实现 化 子 类 的 对 象 进行 组 合 ， 即 系统 需要 对 抽象 化 角色 和 实 
现 化 角色 进行 动态 耦合 。 


(3) 一 个 类 存在 两 个 (或 多 个 ) 独立 变化 的 维度 ， 且 这 两 个 (或 多 个 ) 维度 都 需要 独立 进行 扩 
展 。 


(4) 对 于 那些 不 布 望 使 用 继承 或 因为 多 层 继承 导致 系统 类 的 个 数 和 急剧 增加 的 系统 ， 桥 接 模 式 尤 
为 适用 。 


练习 
Sunny 软 件 公司 欲 开 发 一 个 数据 转换 工具 ， 可 以 将 数据 库 中 的 数据 转换 成 多 种 文件 格式 ， 


例如 txt、xml、pdf 等 格式 ， 同 时 该 工具 需要 支持 多 种 不 同 的 数据 库 。 试 使 用 桥接 模式 对 
其 进行 设计 。 
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组 合 模 式 -Composite Pattern 


2 @ 
组 合 模 式 -Composite Pattern 
组 合 模式 -Composite Pattern 【学 习 难 度 : 交友 友 六 六 ， 使 用 频率 : 交友 交友 六 】 


e 组 合 模式 -Composite Pattern 
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树 形 结 构 的 处 理 一 一 组 合 模式 (一) 
树 形 结构 的 处 理 一 一 组 合 模式 (一 ) 


树 形 结构 在 软件 中 随处 可 见 ， 例 如 操作 系统 中 的 目录 结构 、 应 用 软件 中 的 菜单 、 办 公 系 统 中 
的 公司 组 织 结构 等 等 ， 如 何 运用 面向 对 象 的 方式 来 处 理 这 种 树 形 结构 是 组 合 模式 需要 解决 的 
问题 ， 组 合 模式 通过 一 种 巧妙 的 设计 方案 使 得 用 户 可 以 一 致 性 地 处 理 整 个 树 形 结构 或 者 树 形 
结构 的 一 部 分 ， 也 可 以 一 致 性 地 处 理 树 形 结构 中 的 叶子 节点 (不 包含 子 节点 的 节点 ) 和 容器 
节点 (包含 子 节点 的 节点 ) 。 下 面 将 学 习 这 种 用 于 处 理 树 形 结构 的 组 合 模式 。 


11.1 设计 杀毒 软件 的 框架 结构 


Sunny 软 件 公司 欲 开 发 一 个 杀毒 (AntiVirus) 软 件 ， 该 软件 既 可 以 对 某 个 文件 夹 (Foldem 杀 毒 ， 也 
可 以 对 某 个 指定 的 文件 (File) 进 行 杀毒 。 该 杀毒 软件 还 可 以 根据 各 类 文件 的 特点 ， 为 不 同类 型 

的 文件 提供 不 同 的 杀毒 方式 ， 例 如 图 像 文 件 (ImageFile) 和 文本 文件 (TextFile) 的 杀毒 方式 就 有 所 
差异 。 现 需要 提供 该 杀毒 软件 的 整体 框架 设计 方案 。 


在 介绍 Sunny 公 司 开 发 人 员 提 出 的 初始 解决 方案 之 前 ， 我 们 先 来 分 析 一 下 操作 系统 中 的 文件 目 
录 结 构 ， 例 如 在 Windows 操 作 系 统 中 ， 存 在 如 图 11-1 所 示 目 录 结 构 : 


文件 日 ”编辑 (E) ”前 看 (VM) 工具 中 ”帮助 (里 ) 
组 织 了 包含 到 库 中 Y 共享 了 刻录 


新 建文 件 夫 
则 Windows 全 Ya 
点 addins 县 外 外 出 站 
出 AppCompat Ee 
Corporate Help mui nvcpl OEM Windows ADODC98. 
点 AppPatch CHI 


@ B® 


则 Branding DAO35.CN DAO35.HL DATRPT98 DATRPT98 DBGRID96 DBGRID96 ”DBGRID98 
Bcsc T p .CHI .CHM .CNT .HLP .CHI 


ope @ |@ | EE 


点 diagnostics JETERR35. JETSQL35. JETSQL35. MAPI98.C MAPI98.C MASKED9 MASKED9 
HLP CNT HLP HI HM 8.CHI 8.CHM 


点 DigitalLocker 


点 Downloaded Installat Ey ay by EE 
出 Downloaded Prograr 性 | 书 - | 已; 一 - 

出 | MSWNSK PIiCCLP98. PICCLP98. RDO98.CH RDO98.CH SYSINF98. SYSINF98. 
98.CHM CHI CHM M CHI CHM 


出 ES3 EE 

也 Fonts 

VEENDF98 VEENDF98 
.CHI .CHM 


点 en-US 


点 Globalization 

点 Help 

Bd ME 

号 inf 

$B L2Schemas 

康 LiveKernelReports 
出 Logs 





图 11-1 Windows 目 录 结 构 
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图 11-1 可 以 简化 为 如 图 11-2 所 示 树 形 目 录 结 构 : 


Sunny 的 资料 





葵花 宝典 .doc 





张无忌 .gif 九 阴 真 经 .txt 
图 11-2 树 形 目录 结构 示意 图 


我 们 可 以 看 出 ， 在 图 11-2 中 包含 文件 (灰色 节点 ) 和 文件 夹 (白色 节点 ) 两 类 不 同 的 元 素 ， 其 
中 在 文件 夹 中 可 以 包含 文件 ， 还 可 以 继续 包含 子 文件 夹 ， 但 是 在 文件 中 不 能 再 包含 子 文件 或 

者 子 文件 来。 在 此 ， 我 们 可 以 称 文件 夹 为 容器 (Container)， 而 不 同类 型 的 各 种 文件 是 其 成 员 ， 
也 称 为 叶子 (Leaf)， 一 个 文件 夹 也 可 以 作为 另 一 个 更 大 的 文件 夹 的 成 员 。 如 果 我 们 现在 要 对 某 
一 个 文件 夹 进行 操作 ， 如 查找 文件 ， 那 么 需要 对 指定 的 文件 夹 进行 遍历 ， 如 果 存 在 子 文件 夹 

则 打开 其 子 文件 夹 继续 人 遍历， 如果 是 文件 则 判断 之 后 返回 查找 结果 。 


Sunny 软 件 公司 的 开发 人 员 通 过 分 析 ， 决 定 使 用 面向 对 象 的 方式 来 实现 对 文件 和 文件 夹 的 操 
作 ， 定 义 了 如 下 图 像 文件 类 ImageFile、 文 本 文件 类 TextFile 和 文件 夹 类 Folder : 


// 为 了 突出 核心 框架 代码 ， 我 们 对 杀毒 过 程 的 实现 进行 了 大 量 简 化 
import java.util.*,; 


// 图 像 文件 类 
class ImageFile { 
private String name; 


public ImageFile(String name) { 
this.name = name; 


} 


public void killVirus() { 
// 简 化 代码 ， 模 拟 杀毒 


System.out.println("---- 对 图 像 文件 '" + name + " "进行 杀毒 " ) ; 
} 

} 

// 文 本 文件 类 


class TextFile { 
private String name; 


public TextFile(String name) { 
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this.name = name; 


} 


public void killVirus() { 
// 简 化 代码 ， 模 拟 杀毒 


System.out.println("---- 对 文本 文件 '" + name + " "进行 杀毒 ") ; 
} 

} 

// 文 件 夹 类 


class Folder { 

private String name; 

// 定 义 集合 folderList， 用 于 存储 Folder 类 型 的 成 员 

private ArrayList<Folder> folderList = new ArrayList<Folder>(); 

// 定 义 集合 imageList， 用 于 存储 ImageFile 类 型 的 成 员 

private ArrayList<ImageFile> imageList = new ArrayList<ImageFile>(); 
// 定 义 集合 textList， 用 于 存储 TextFile 类 型 的 成 员 

private ArrayList<TextFile> textList = new ArrayList<TextFile>(); 


public Folder(String name) { 
this.name = name; 


} 


// 增 加 新 的 Folder 类 型 的 成 员 
public void addFolder(Folder f) { 
folderList.add(f); 


} 


// 增 加 新 的 ImageFile 类 型 的 成 员 
public void addIimageFile(ImageFile image) { 
imageList.add(image); 


} 


// 增 加 新 的 TextFile 类 型 的 成 员 
public void addTextFile(TextFile text) { 
textList.add( text); 


} 


// 需 提供 三 个 不 同 的 方法 removeFolder()、removeImageFile() 和 removeTextFile( 
// 需 提供 三 个 不 同 的 方法 getChildFolder(int i)、getchildImageFile(int i) 和 g( 


public void killVirus() { 
System.out.println("**** 对 文件 来 '" + name + "' 进 行 杀毒 "); // 模 拟 杀 毒 


// 如 果 是 Folder 类 型 的 成 员 ， 递 归 调 用 Folder 的 killVirus() 方 法 
for(Object obj : folderList) { 
((Folder)obj).killVirus( ); 


} 


// 如 果 是 ImageFile 类 型 的 成 员 ， 调 用 ImageFile 的 KkillVirus() 方 法 
for(Object obj : imageList) { 
((ImageFile)obj).killVirus(); 
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} 


// 如 果 是 TextFile 类 型 的 成 员 ， 调 用 TextFile 的 killVirus() 方 法 
for(Object obj : textList) { 
((TextFile)obj).killVirus(); 

} 

} 

} 


编写 如 下 客户 端 测试 代码 进行 测试 : 


class Client { 

public static void main(String args[]) { 
Folder folder1,folder2,folder3; 

folder1 = new Folder ("Sunny 的 资 次 es 
folder2 = new Folder ("图 像 文件 "); 

folder3 = new Folder ("文本 文件 ")， 


ImageFile Image1, image2; 
image1 = new ImageFile(" 小 龙 女 .jpg"); 
image2 = new ImageFile(" 张 无 态 .gif")， 


TextFile text1, text2; 
text1 = new TextFile(" 九 阴 tt) 
text2 = new TextFile(" 英 花 宝典 .doc" ) ; 


folder2.addImageFile(image1); 
folder2.addImageFile(image2); 
folder3.addTextFile(text1); 
folder3.addTextFile( text2); 
folderi.addFolder (folder2); 
folderi.addFolder (folder3); 


folder1.killVirus(); 


} 
} 


编译 并 运行 程序 ， 输 出 结果 如 下 : 


*xxx 对 文件 夹 'Sunny 的 资料 ' 进 行 杀 毒 
x*x*x% 对 文件 夹 ' 图 像 文件 ' 进行 杀毒 
---- 对 图 像 文件 ' 小 龙 女 .jpg ' 进行 
---- 对 图 像 文件 ， 
xxxx 对 文件 来 "文本 文件 ! 进 行 杀毒 

---- 对 文本 文件 ' 九 阴 黄 经 ， txt' 进 行 杀毒 
---- 对 文本 文件 "黄花 宝典 .doc ' 进 行 杀毒 


Sunny 公 司 开 发 人 员 “ 成 功 ”实现 了 杀毒 软件 的 框架 设计 ， 但 通过 仔细 分 析 ， 发 现 该 设计 方案 存 
在 如 下 问题 : 


(1) 文件 夹 类 Folder 的 设计 和 实现 都 非常 复杂 ， 需 要 定义 多 个 集合 存储 不 同类 型 的 成 员 ， 而 且 


需要 针对 不 同 的 成 员 提供 增加 、 删 除 和 获取 等 管理 和 访问 成 员 的 方法 ， 存 在 大 量 的 元 余 代 
码 ， 系 统 维护 较为 困难 ; 
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(2) 由 于 系统 没有 提供 抽象 层 ， 客 户 端 代码 必须 有 区 别 地 对 待 充当 容器 的 文件 夹 Folder 和 充当 
叶子 的 ImageFile 和 TextFile， 无 法 统一 对 它们 进行 处 理 ; 


(3) 系统 的 灵活 性 和 可 扩展 性 差 ， 如 果 需 要 增加 新 的 类 型 的 叶子 和 容器 都 需要 对 原 有 代码 进行 
修改 ， 例 如 如 果 需 要 在 系统 中 增加 一 种 新 类 型 的 视频 文件 VideoFile， 则 必须 修改 Folder 类 的 源 
人 代码， 否则 无 法 在 文件 夹 中 添加 视频 文件 。 


面 对 以 上 问题 ，Sunny 软 件 公司 的 开发 人 员 该 如 何 来 解决 ? 这 就 需要 用 到 本 章 将 要 介绍 的 组 合 


模式 ， 组 合 模式 为 处 理 树 形 结构 提供 了 一 种 较为 完美 的 解决 方案 ， 它 描述 了 如 何 将 容器 和 叶 
子 进行 递归 组 合 ， 使 得 用 户 在 使 用 时 无 须 对 它们 进行 区 分 ， 可 以 一 致 地 对 待 容 器 和 叶子 。 
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11.2 组 合 模式 概述 


对 于 树 形 结构 ， 当 容器 对 象 (如 文件 夹 ) 的 菜 一 个 方法 被 调用 时 ， 将 遍历 整个 树 形 结构 ， 寻 
找 也 包含 这 个 方法 的 成 员 对 象 ( 可 以 是 容器 对 象 ， 也 可 以 是 叶子 对 象 ) 并 调用 执行 ， 牵 一 而 
动 百 ， 其 中 使 用 了 递归 调用 的 机 制 来 对 整个 结构 进行 处 理 。 由 于 容器 对 象 和 叶子 对 象 在 功能 
上 的 区 别 ， 在 使 用 这 些 对 象 的 代码 中 必须 有 区 别 地 对 待 容器 对 象 和 叶子 对 象 ， 而 实际 上 大 多 
数 情况 下 我 们 希望 一 致 地 处 理 它 们 ， 因 为 对 于 这 些 对 象 的 区 别 对 待 将 会 使 得 程序 非常 复杂 。 
组 合 模式 为 解决 此 类 问题 而 诞生 ， 它 可 以 让 叶子 对 象 和 容器 对 象 的 使 用 具有 一 致 性 。 


组 合 模式 定义 如 下 : 

组 合 模式 (Composite Pattern) : 组 合 多 个 对 象形 成 树 形 结 构 以 表示 具有 “整体 一 部 分 ”关系 的 层 
次 结构 。 组 合 模式 对 单个 对 象 〈 即 叶子 对 象 ) 和 组 合 对 象 〈 即 容器 对 象 ) 的 使 用 具有 一 致 
性 ， 组 合 模式 又 可 以 称 为 “整体 一 部 分 (Part-Whole) 模 式 ， 它 是 一 种 对 象 结构 型 模式 。 


在 组 合 模式 中 引入 了 抽象 构件 类 Component， 它 是 所 有 容器 类 和 叶子 类 的 公共 父 类 ， 客 户 端 针 
对 Component 进 行 编程 。 组 合 模式 结构 如 图 11-3 所 示 : 


| 
| + operation () 
+ add (Component c) 
+ remove (Component c) 
+ getChild (int i) 
ra 













+ operation () 
|+ add (Component c) 

+ remove (Component c) 
+ getChild (int i) 






二 
for(Component child:children) { 


child .operation(); 
} 





图 11-3 组 合 模 式 结 构图 
在 组 合 模式 结构 图 中 包含 如 下 几 个 角色 : 


e Component (抽象 构件 ) : 它 可 以 是 接口 或 抽象 类 ， 为 叶子 构件 和 容器 构件 对 象 声 明 接口 ， 
在 该 角色 中 可 以 包含 所 有 子 类 共有 行为 的 声明 和 实现 。 在 抽象 构件 中 定义 了 访问 及 管理 它 的 
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子 构件 的 方法 ， 如 增加 子 构件 、 删 除 子 构件 、 获 取 子 构件 等 。 


e Leaf (叶子 构件 ) : 它 在 组 合 结 构 中 表示 叶子 节点 对 象 ， 叶 子 节点 没有 子 节点 ， 它 实现 了 在 
抽象 构件 中 定义 的 行为 。 对 于 那些 访问 及 管理 子 构件 的 方法 ， 可 以 通过 异常 等 方式 进行 处 
理 。 


e@ Composite (容器 构件 ) : 它 在 组 合 结构 中 表示 容器 节点 对 象 ， 容 器 节点 包含 子 节点 ， 其 子 
节点 可 以 是 叶子 节点 ， 也 可 以 是 容器 节点 ， 它 提供 一 个 集合 用 于 存储 子 节点 ， 实 现 了 在 抽象 
构件 中 定义 的 行为 ， 包 括 那些 访问 及 管理 子 构件 的 方法 ， 在 其 业务 方法 中 可 以 递归 调用 其 子 
节点 的 业务 方法 。 


组 合 模式 的 关键 是 定义 了 一 个 抽象 构件 类 ， 它 既 可 以 代表 叶子 ， 又 可 以 代表 容器 ， 而 客户 端 
针对 该 抽象 构件 类 进行 编程 ， 无 须知 道 它 到 底 表示 的 是 叶子 还 是 容器 ， 可 以 对 其 进行 统一 处 
理 。 同 时 容器 对 象 与 抽象 构件 类 之 间 还 建立 一 个 聚合 关联 关系 ， 在 容器 对 象 中 既 可 以 包含 叶 
子 ， 也 可 以 包含 容器 ， 以 此 实现 递归 组 合 ， 形 成 一 个 树 形 结构 。 


如 果 不 使 用 组 合 模式 ， 客 户 端 代码 将 过 多 地 依赖 于 容器 对 象 复杂 的 内 部 实现 结构 ， 容 
内 部 实现 结构 的 变化 将 引起 客户 代码 的 频繁 变化 ， 带 来 了 代码 维护 复杂 、 可 扩展 性 关 
端 组 合 模 式 的 引入 将 在 一 定 程度 上 解决 这 些 问题 。 


jk 前 
也 
闫 


下 面 通过 简单 的 示例 代码 来 分 析 组 合 模式 的 各 个 角色 的 用 途 和 实现 。 对 于 组 合 模式 中 的 抽象 
构件 角色 ， 其 典型 代码 如 下 所 示 : 


abstract class Component { 
public abstract void add(Component c); // 增 加 成 员 
public abstract void remove(Component c); // 删 除 成 员 
public abstract Component getChild(int i); // 获 取 成 员 
public abstract void operation(); // 业 务 方法 


} 


一 般 将 抽象 构件 类 设计 为 接口 或 抽象 类 ， 将 所 有 子 类 共有 方法 的 声明 和 实现 放 在 抽象 构件 类 
中 。 对 于 客户 端 而 言 ， 将 针对 抽象 构件 编程 ， 而 无 须 关心 其 具体 子 类 是 容器 构件 还 是 叶子 构 
件 。 


如 果 继 承 抽象 构件 的 是 叶子 构件 ， 则 其 典型 代码 如 下 所 示 : 


class Leaf extends Component { 
public void add(Component c) { 
// 异 常 处 理 或 错误 提示 
} 


public void remove(Component c) { 
// 异 常 处 理 或 错误 提示 
} 


public Component getchild(int i) { 
// 弄 常 处 理 或 错误 提示 
return null; 


} 


public void operation() { 
// 叶 子 构 件 具体 业务 方法 的 实现 
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作为 抽象 构件 类 的 子 类 ， 在 叶子 构件 中 需要 实现 在 抽象 构件 类 中 声明 的 所 有 方法 ， 包 括 业 务 
方法 以 及 管理 和 访问 子 构件 的 方法 ， 但 是 叶子 构件 不 能 再 包含 子 构件 ， 因 此 在 叶子 构件 中 实 
现 子 构件 管理 和 访问 方法 时 需要 提供 异常 处 理 或 错误 提示 。 当 然 ， 这 无 疑 会 给 叶子 构件 的 实 
现 带 来 麻烦 。 


如 果 继 承 抽象 构件 的 是 容器 构件 ， 则 其 典型 代码 如 下 所 示 : 


class Composite extends Component { 
private ArrayList<Component> list = new ArrayList<Component>(); 


public void add(Component c) { 
list.add(c); 
} 


public void remove(Component c) { 
list.remove(c); 
} 


public Component getcChild(int i) { 
return (Component)1list.get(i); 
} 


public void operation() { 
// 容 器 构件 具体 业务 方法 的 实现 
// 递 归 调 用 成 员 构件 的 业务 方法 
for(Object obj:list) { 
((Component)obj).operation( ); 


} 


在 容器 构件 中 实现 了 在 抽象 构件 中 声明 的 所 有 方法 ， 既 包 括 业 务 方法 ， 也 包括 用 于 访问 和 管 
理 成 员 子 构件 的 方法 ， ’ oadd() . 、remove() 和 getChild() 等 方法 。 需 要 注意 的 是 在 实现 具体 业务 方 
法 时 ， 由 于 容器 构件 充当 的 是 容器 角色 ， 和 包含 成 员 构 件 ， 因此 它 将 调用 其 成 员 构 件 的 业务 方 
法 。 在 组 合 模 式 结 构 中 ， 由 于 容器 构件 中 仍然 可 以 包含 容器 构件 ， 因 此 在 对 容器 构件 进行 处 
理 时 需要 使 用 递归 算法 ， 即 在 容器 构件 的 operation() 方 法 中 递归 调用 其 成 员 构件 的 operation() 方 
法 。 


思考 


在 组 合 模式 结构 图 中 ， 如 果 聚 合 关联 关系 不 是 从 Composite 到 Component 的 ， 而 是 从 Composite 
到 Leaf 的 ， 如 图 11-4 所 示 ， 会 产生 怎样 的 结果 ? 
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图 11-4 组 合 模 式 思考 题 结构 图 
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11.3 完整 解决 方案 


为 了 让 系统 具有 更 好 的 灵活 性 和 可 扩展 性 ， 客 户 端 可 以 一 致 地 对 待 文件 和 文件 夹 ，Sunny 公 司 
开发 人 员 使 用 组 合 模式 来 进行 杀毒 软件 的 框架 设计 ， 其 基本 结构 如 图 11-5 所 示 : 


AbstractFile 
{abstract} 


| °F 
+ add (AbstractFile file) : void 
+ remove (AbstractFile file) : void 
+ getChild (int i) : AbstractFile 
+ killVirus () :void 

A pa 


























v 

- filleList : ArrayList 

- name :Strng 

+ Folder (String name) 
+ add (AbstractFile file) :void 

+ remove (AbstractFile file) :void 

+ getChild (int 1) : AbstractFile 
+ killVirus () -void 










me 
+ ImageFile (String name) 
+ add (AbstractFile file) void 
+ remove (AbstractFile file) :void 
+ getChild (int 1) :AbstractFile || |+ getChild (int ) - AbstractFile 
+ killVirus () :void + killVirus () -void 


| Toxin 
-name :Sting 
+ TextFile (String name) 
+ add (AbstractFile file) : void 

+ remove (AbstractFile file) : void 

+ getChild (int i) : AbstractFile 
| : void 


-name :String 
+ VideoFile (String name) 
+ add (AbstractFile file) :void 
+ remove (AbstractFile fle) :void 

























图 11-5 杀毒 软件 框架 设计 结构 图 


在 图 11-5 中 ，AbstractFile 充 当 抽 象 构件 类 ，Folder 充 当 容器 构件 类 ，TmageFile、TextFile 和 
VideoFile 充 当 叶 子 构件 类 。 完 整 代码 如 下 所 示 : 


import java.util.*,; 


// 抽 象 文件 类 : 抽象 构件 

abstract class AbstractFile { 
public abstract void add(AbstractFile file); 
public abstract void remove(AbstractFile file); 
public abstract AbstractFile getChild(int 1); 
public abstract void killVirus(); 


} 


// 图 像 文件 类 : 叶子 构件 
class ImageFile extends AbstractFile { 
private String name; 


public ImageFile(String name) { 
this.name = name; 
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} 


public void add(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 1 ")， 
} 


public void remove(AbstractFile file) { 
System,.out,.printLn(" 对 不 起 ， 不 支持 该 方法 1 ")， 
} 


public AbstractFile getChild(int i) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 1 ")， 
return null; 


} 
public void killVirus() { 

// 模 拟 杀毒 

System.out.println("---- 对 图 像 文件 '" + name + " "进行 杀毒 ") ; 
} 


} 


// 文 本 文件 类 : 叶子 构件 
class TextFile extends AbstractFile { 
private String name; 


public TextFile(String name) { 
this.name = name; 
} 


public void add(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 ! ")， 
} 


public void remove(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 ! ")，; 
} 


public AbstractFile getChild(int i) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 1 ")， 
return null; 


} 
public void killVirus() { 

// 模 拟 杀毒 

System.out.println("---- 对 文本 文件 '" + name + " "进行 杀毒 ") ; 
} 


} 


// 视 频 文件 类 : 叶子 构件 
class VideoFile extends AbstractFile { 
private String name; 


public VideoFile(String name) { 
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this.name = name; 


} 


public void add(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 1 ")， 
} 


public void remove(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 ! ")， 
} 


public AbstractFile getChild(int i) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 ! ")， 
return null; 


} 
public void killVirus() { 

// 模 拟 杀毒 

System.out.println("---- 对 视频 文件 '" + name + "进行 杀毒 ") ; 
} 


// 文 件 夹 类 : 容器 构件 
class Folder extends AbstractFile { 


174 


// 定 义 集合 fileList， 用 于 存储 AbstractFile 类 型 的 成 员 
private ArrayList<AbstractFile> fileList=new ArrayList<AbstractF: 
private String name; 


public Folder(String name) { 
this.name = name; 
} 


public void add(AbstractFile file) { 
fileList.add(file); 
} 


public void remove(AbstractFile file) { 
fileList.remove(file); 
} 


public AbstractFile getChild(int i) { 
return (AbstractFile)fileList.get(i); 
} 


public void killvirus() { 
System.out.println("**** 对 文件 夹 '" + name + "' 进 行 杀毒 "); // 模 : 


// 递 归 调 用 成 员 构 件 的 killVirus() 方 法 
for(Object obj : fileList) { 
((AbstractFile)obj).killVirus(); 








树 形 结 杭 
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编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
// 针 对 抽象 构件 编程 
AbstractFile filel,file2,file3,file4,file5,folder1,folder2 , 千 


folder1 = new Folder("Sunny 的 资料 " ) ; 
folder2 = new Folder(" 图 像 文件 ") ; 
folder3 = new Folder(" 文 本 文件 " ) ， 
folder4 = new Folder(" 视 频 文 件 " ) ; 
file1 = new ImageFile(" 小 龙 女 .jpg"); 
file2 = new ImageFile(" 张 无 辟 .gif" ) ，; 
file3 = new TextFile(" 九 阴 惧 经 ,txt" ) ; 
file4 = new TextFile(" 英 花 宝 典 .doc" ) 
file5 = new VideoFile(" 笑 做 江湖 .rmvb"); 


folder2.add(file1); 
folder2.add(file2); 
folder3.add(file3); 
folder3.add(file4); 
folder4.add(file5s); 
folderi.add(folder2); 
folderi.add(folder3); 
folderi.add(folder4); 


// 从 “Sunny 的 资料 "节点 开始 进行 杀毒 操作 
folderi1.killVirus(); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


*xxx 对 文件 夹 'Sunny 的 资料 ' 进 行 杀毒 
xxxx 对 文件 夹 ! 图 像 文件 ' 进 行 杀毒 
hg 
---- 对 图 像 文件 ' 张 无 辟 过 
**** 对 文件 夹 ' 文 本 文件 ' 进 行 杀毒 
ss 
---- 对 文本 文件 ' 英 花 宝 典 .doc ' 进 
**** 对 文件 夹 ' 视 频 文件 ' 进 行 杀毒 
---- 对 视频 文件 ' 笑 做 江湖 ,rmvb' 进 行 杀 毒 


行 
和 


二 多 


由 于 在 本 实例 中 使 用 了 组 合 模式 ， 在 抽象 构件 类 中 声明 了 所 有 方法 ， 包 括 用 于 管理 和 访问 子 
构件 的 方法 ， 如 add() 方 法 和 remove() 方 法 等 ， ee 
必须 进行 相应 的 异常 处 理 或 错误 提示 。 在 容器 构件 类 Folder 的 killVirus() 方 法 中 将 递归 调用 其 成 
员 对 象 的 killVirus() 方 法 ， 从 而 实现 对 整个 树 形 结构 的 遍历 。 


如 果 需 要 更 换 操 作 节 点 ， 例 如 只 需 对 文件 夹 “ 文 本 文件 ”进行 杀毒 ， 客 户 端 代码 只 需 修 改 一 行 即 
可 ， 将 


代码 : 
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folder1.killVirus( ); 

改 为 : 

folder3.killVirus(); 

输出 结果 如 下 : 

**** 对 文件 夹 ' 文 本 文件 ' 进 行 杀毒 
---- 对 文本 文件 ' 九 阴 扶 经 .txt' 进 行 杀 
---- 对 文本 文件 葵花 宝 典 .doc' 进 和 

在 具体 实现 时 ， 我 们 可 以 创建 图 形 化 界面 让 用 户 选择 所 需 操 作 的 根 节 点 ， 无 须 修 改 源 代码 ， 


符合 “ 开 闭 原则 ”， 客户 端 无 须 关 心 节点 的 层次 结构 ， 可 以 对 所 选 节 点 进行 统一 处 理 ， 提 高 系统 
的 灵活 性 。 
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11.4 透明 组 合 模式 与 安全 组 合 模式 


通过 引入 组 合 模式 ，Sunny 公 司 设计 的 杀毒 软件 具有 良好 的 可 扩展 性 ， 在 增加 新 的 文件 类 型 
时 ， 无 须 修 改 现 有 类 库 代 码 ， 只 需 增 加 一 个 新 的 文件 类 作为 AbstractFile 类 的 子 类 即 可 ， 但 是 
由 于 在 AbstractFile 中 声明 了 大 量 用 于 管理 和 访问 成 员 构 件 的 方法 ， 例 如 add0、removeO 等 方 
法 ， 我 们 不 得 不 在 新 增 的 文件 类 中 实现 这 些 方法 ， 提 供 对 应 的 错误 提示 和 异常 处 理 。 为 了 简 
化 代码 ， 我 们 有 以 下 两 个 解决 方案 : 


解决 方案 一 : 将 叶子 构件 的 add()、remove() 等 方法 的 实现 代码 移 至 AbstractFile 类 中 ， 由 
AbstractFile 提 供 统 一 的 默认 实现 ， 代 码 如 下 所 示 : 


// 提 供 默认 实现 的 抽象 构件 类 
abstract class AbstractFile { 
public void add(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 ! ")， 
} 


public void remove(AbstractFile file) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 1 ")， 
} 


public AbstractFile getChild(int i) { 
System.out.println(" 对 不 起 ， 不 支持 该 方法 ! ")， 
return null; 


} 


public abstract void killVirus(); 
} 


如 果 客 户 端 代 码 针 对 抽象 类 AbstractFile 编 程 ， 在 调用 文件 对 象 的 这 些 方法 时 将 出 现 错误 提 
示 。 如 果 不 希 望 出 现任 何 错误 提示 ， 我 们 可 以 在 客户 端 定 义 文件 对 象 时 不 使 用 抽象 层 ， 而 直 
接 使 用 具体 叶子 构件 本 身 ， 客 户 端 代码 片段 如 下 所 示 : 


class Client { 
public static void main(String args[]) { 
// 不 能 透明 处 理 叶 子 构件 
ImageFile file1,file2， 
TextFile file3,file4; 
VideoFile file5， 
AbstractFile folder1,folder2,folder3,folder4; 
// 其 他 代码 省 略 


} 


这 样 就 产生 了 一 种 不 透明 的 使 用 方式 ， 即 在 客户 端 不 能 全 部 针对 抽象 构件 类 编程 ， 需 要 使 用 
具体 叶子 构件 类 型 来 定义 叶子 对 象 。 
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解决 方案 二 : 除 此 之 外 ， 还 有 一 种 解决 方法 是 在 抽象 构件 AbstractFile 中 不 声明 任何 用 于 访问 
和 管理 成 员 构 件 的 方法 ， 代 码 如 下 所 示 : 


abstract class AbstractF1ile { 
public abstract void killVirus(); 
} 


此 时 ， 由 于 在 AbstractFile 中 没有 声明 add()、remove() 等 访问 和 管理 成 员 的 方法 ， 其 叶子 构件 子 
类 无 须 提供 实现 ; 而 且 无 论 客 户 端 如 何 定义 叶子 构件 对 象 都 无 法 调用 到 这 些 方法 ， 不 需要 做 
任何 错误 和 姬 常 处 理 ， 容 器 构件 再 根据 需要 增加 访问 和 管理 成 员 的 方法 ， 但 这 时 候 也 存在 一 
个 问题 : 客户 端 不 得 不 使 用 容器 类 本 身 来 声明 容器 构件 对 象 ， 否 则 无 法 访问 其 中 新 增 的 
add()、remove() 等 方法 ， 如 果 客 户 端 一 致 性 地 对 待 叶子 和 容器 ， 将 会 导致 容器 构件 的 新 增 对 客 
户 端 不 可 见 ， 窜 户 端 代码 对 于 容器 构件 无 法 再 使 用 抽象 构件 来 定义 ， 客 户 端 代码 片段 如 下 所 
示 : 


class Client { 
public static void main(String args[]) { 


AbstractFile filel1,file2,file3,file4,files; 
Folder folder1,folder2,folder3,folder4; // 不 能 透明 处 理 容器 构件 
// 其 他 代码 省 略 


} 


在 使 用 组 合 模式 时 ， 根 据 抽 象 构 件 类 的 定义 形式 ， 我 们 可 将 组 合 模式 分 为 透明 组 合 模式 和 安 
全 组 合 模 式 两 种 形式 : 


(1) 透明 组 合 模式 


透明 组 合 模式 中 ， 抽 象 构 件 Component 中 声明 了 所 有 用 于 管理 成 员 对 象 的 方法 ， 包 括 add0、 
remove() 以 及 getChild() 等 方法 ， 这 样 做 的 好 处 是 确保 所 有 的 构件 类 都 有 相同 的 接口 。 在 客户 端 
看 来 ， 叶 子 对 象 与 容器 对 象 所 提供 的 方法 是 一 致 的 ， 客 户 端 可 以 相同 地 对 待 所 有 的 对 象 。 透 
明 组 合 模式 也 是 组 合 模式 的 标准 形式 ， 虽 然 上 面 的 解决 方案 一 在 客户 端 可 以 有 不 透明 的 实现 
方法 ， 但 是 由 于 在 抽象 构件 中 包含 add0、removeO 等 方法 ， 因 此 它 还 是 透明 组 合 模式 ， 透 明 组 
合 模式 的 完整 结构 如 图 11-6 所 示 : 
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+ operation () 

+ add (Component c) 

+ remove (Component c) 

+ getChild (int i) 
六 从 







+ operation () + operation () 

+ add (Component c) + add (Component c) 

+ remove (Component c) + remove (Component c) 
+ getChild (int i) + getChild (int i) 













图 11-6 透明 组 合 模式 结构 图 


透明 组 合 模式 的 缺点 是 不 够 安全 ， 因 为 叶子 对 象 和 容器 对 象 在 本 质 上 是 有 区 别 的 。 叶 子 对 象 
不 可 能 有 下 一 个 层次 的 对 象 ， 即 不 可 能 包 人 金成 员 对 象 ， 因 此 为 其 提供 add0、removeO 以 及 
getChild() 等 方法 是 没有 意义 的 ， 这 在 编译 阶段 不 会 出 错 ， 但 在 运行 阶段 如 果 调 用 这 些 方法 可 
能 会 出 错 (如 果 没 有 提供 相应 的 错误 处 理 代 码 ) 。 


(2) 安全 组 合 模 式 
安全 组 合 模式 中 ， 在 抽象 构件 Component 中 没有 声明 任何 用 于 管理 成 员 对 象 的 方法 ， 而 是 在 
Composite 类 中 声明 并 实现 这 些 方法 。 这 种 做 法 是 安全 的 ， 因 为 根本 不 向 叶子 对 象 提 供 这 些 管 


理 成 员 对 象 的 方法 ， 对 于 叶子 对 象 ， 客 户 端 不 可 能 调用 到 这 些 方法 ， 这 就 是 解决 方案 二 所 采 
用 的 实现 方式 。 安 全 组 合 模式 的 结构 如 图 11-7 所 示 : 
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树 形 结 构 的 处 理 








+ operation () 
+ add (Component c) 





+ remove (Component c) 
+ getChild (int ) 


图 11-7 安全 组 合 模式 结构 图 


安全 组 合 模式 的 缺点 是 不 够 透明 ， 因 为 叶子 构件 和 容器 构件 具有 不 同 的 方法 ， 且 容器 构件 中 
那些 用 于 管理 成 员 对 象 的 方法 没有 在 抽象 构件 类 中 定义 ， 因 此 客户 端 不 能 完全 针对 抽象 编 
程 ， 必 须 有 区 别 地 对 待 叶子 构件 和 容器 构件 。 在 实际 应 用 中 ， 安 全 组 合 模式 的 使 用 频率 也 非 
常 高 ， 在 Java AWT 中 使 用 的 组 合 模式 就 是 安全 组 合 模式 。 
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11.5 公司 组 织 结 构 


在 学 习 和 使 用 组 合 模 式 时 ，Sunny 软 件 公司 开发 人 员 发 现 树 形 结构 其 实 随 处 可 见 ， 例 如 Sunny 
公司 的 组 织 结构 就 是 “一 棵 标准 的 树 ”， 如 图 11-8 所 示 : 


上 海 分 公司 研发 
部 


Sunny 公 司 北京 总 部 


上 海 分 公司 财务 


部 


上 海 分 公司 人 力 资 
源 部 


深圳 分 公司 研发 
部 


深圳 分 公司 深圳 分 公司 财务 
部 





深圳 分 公司 人 力 资 





源 部 


图 11-8 Sunny 公 司 组 织 结构 图 


在 Sunny 软 件 公司 的 内 部 办 公 系 统 Sunny OA 系统 中 ， 有 一 个 与 公司 组 织 结构 对 应 的 树 形 菜 单 ， 
行政 人 员 可 以 给 各 级 单位 下 发 通知 ， 这 些 单位 可 以 是 总 公司 的 一 个 部 门 ， 也 可 以 是 一 个 分 公 

司 ， 还 可 以 是 分 公司 的 一 个 部 门 。 用 户 只 需要 选择 一 个 根 节点 即 可 实现 通知 的 下 发 操作 ， 而 

无 须 关心 具体 的 实现 细节 。 这 不 正 是 组 合 模式 的 “特长 * 吗 ? 于 是 Sunny 公 司 开 发 人 员 绘 制 了 如 
图 11-9 所 示 结 构图 : 
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+ 发 通知 () 
A A 


图 11-9 Sunny 公 司 组 织 结构 组 合 模式 示意 图 

在 图 11-9 中 ，“ 单 位 ”充当 了 抽象 构件 角色 ，“ 公 司 ” 充 当 了 容器 构件 角色 ，“ 研 发 部 ?”、“ 财 务 
部 ”和 “人 力 资 源 部 ”充当 了 叶子 构件 角色 。 

如 何 编码 实现 图 11-9 中 的 “公司 ”类 ? 

11.6 组 合 模 式 总 结 


组 合 模式 使 用 面向 对 象 的 思想 来 实现 树 形 结构 的 构建 与 处 理 ， 描 述 了 如 何 将 容器 对 象 和 叶子 
对 象 进 行 递归 组 合 ， 实 现 简单 ， 灵 活性 好 。 由 于 在 软件 开发 中 存在 大 量 的 树 形 结 构 ， 因 此 组 
合 模 式 是 一 种 使 用 频率 较 高 的 结构 型 设计 模式 ，Java SE 中 的 AWT 和 Swing 包 的 设计 就 基于 组 
合 模 式 ， 在 这 些 界面 包 中 为 用 户 提 供 了 大 量 的 容器 构件 (如 Container) 和 成 员 构 件 (如 
Checkbox、Button 和 TextComponent 等 ) ， 其 结构 如 图 11-10 所 示 : 


Component 
EN 















- component : Component[] | 过: 


TextComponent 


图 11-10 AWT 组 合 模 式 结构 示意 图 





在 图 11-10 中 ，Component 类 是 抽象 构件 ，Checkbox、Button 和 TextComponent 是 叶子 构件 ， 而 
Container 是 容器 构件 ， 在 AWT 中 包含 的 叶子 构件 还 有 很 多 ， 因 为 篇 幅 限制 没有 在 图 中 一 一 列 
出 。 在 一 个 容器 构件 中 可 以 包含 叶子 构件 ， 也 可 以 继续 包含 容器 构件 ， 这 些 叶 子 构件 和 容器 
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构件 一 起 组 成 了 复杂 的 GUI 界面 。 


除 此 以 外 ， 在 XML 解析、 组 织 结构 树 处 理 、 文 件 系 统 设 计 等 领域 ， 组 合 模式 都 得 到 了 广泛 应 
用 o 


1. 主要 优点 
组 合 模式 的 主要 优点 如 下 : 


(1) 组 合 模式 可 以 清楚 地 定义 分 层次 的 复杂 对 象 ， 表 示 对 象 的 全 部 或 部 分 层次 ， 它 让 客户 端 忽 
略 了 层次 的 差异 ， 方 便 对 整个 层次 结构 进行 控制 。 


(2) 客户 端 可 以 一 致 地 使 用 一 个 组 合 结构 或 其 中 单个 对 象 ， 不 必 关 心 处 理 的 是 单个 对 象 还 是 整 
个 组 合 结构 ， 简 化 了 客户 端 代码 。 


(3) 在 组 合 模式 中 增加 新 的 容器 构件 和 叶子 构件 都 很 方便 ， 无 须 对 现 有 类 库 进 行 任何 修改 ， 符 
合 “ 开 闭 原则 ”。 


(4) 组 合 模式 为 树 形 结构 的 面向 对 象 实现 提供 了 一 种 灵活 的 解决 方案 ， 通 过 叶子 对 象 和 容器 对 
象 的 递归 组 合 ， 可 以 形成 复杂 的 树 形 结构 ， 但 对 树 形 结 构 的 控制 却 非常 简单 。 


1. 主要 缺点 
组 合 模式 的 主要 缺点 如 下 : 


在 增加 新 构件 时 很 难 对 容器 中 的 构件 类 型 进行 限制 。 有 时 候 我 们 希望 一 个 容器 中 只 
特定 类 型 的 对 象 ， 例 如 在 菜 个 文件 夹 中 只 能 包含 文本 文件 ， 使 用 组 合 模式 时 ， 不 外 


进行 类 型 检查 来 实现 ， 这 个 实现 过 程 较为 复杂 。 
1. 适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 组 合 模式 : 


(1) 在 具有 整体 和 部 分 的 层次 结构 中 ， 和 希望 通过 一 种 方式 忽略 整体 与 部 分 的 差异 ， 客 户 端 可 以 
一 致 地 对 待 它们 。 


(2) 在 一 个 使 用 面向 对 象 语言 开发 的 系统 中 需要 处 理 一 个 树 形 结构 。 


(3) 在 一 个 系统 中 能 够 分 离 出 叶子 对 象 和 容器 对 象 ， 而 且 它 们 的 类 型 不 固定 ， 需 要 增加 一 些 新 
的 类 型 。 


练习 
Sunny 软 件 公司 欲 开 发 一 个 界面 控件 库 ， 界 面 控件 分 为 两 大 类 ， 一 类 是 单元 控件 ， 例 如 按 


钮 、 文 本 框 等 ， 一 类 是 容器 控件 ， 例 如 窗 体 、 中 间 面 板 等 ， 试 用 组 合 模式 设计 该 界面 控 
件 库 。 
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装饰 模式 -Decorator Pattern 


装饰 模式 -Decorator Pattern 【学 习 难 度 : 次 太太 六 六 ， 使 用 频率 : 次 太太 六 六 】 


装饰 模式 -Decorator Pattern 
o 术 

o 扩展 系统 功能 装饰 模式 (二 
o 扩展 系统 功能 装饰 模式 (三 
o 扩展 系统 功能 装饰 模式 (四 
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扩展 系统 功能 一 一 装饰 模式 (一 ) 
扩展 系统 功能 一 一 装饰 模式 (一 ) 


尽管 目前 房价 依旧 很 高 ， 但 还 是 阻止 不 了 大 家 对 新 房 的 渴望 和 买房 的 热情 。 如 果 大 家 买 的 是 
毛坯 房 ， 无 疑 还 有 一 项 艰巨 的 任务 要 面 对 ， 那 就 是 装修 。 对 新 房 进行 装修 并 没有 改变 房屋 用 
于 居住 的 本 质 ， 但 它 可 以 让 房子 变 得 更 漂亮 、 更 温 声 、 更 实用 、 更 能 满足 居家 的 需求 。 在 软 
件 设计 中 ， 我 们 也 有 一 种 类 似 新 房 装 修 的 技术 可 以 对 已 有 对 象 ( 新 房 ) 的 功能 进行 扩展 〈 装 
修 ) ， 以 获得 更 加 符合 用 户 需求 的 对 象 ， 使 得 对 象 具有 更 加 强大 的 功能 。 这 种 技术 对 应 于 一 
种 被 称 之 为 装饰 模式 的 设计 模式 ， 本 章 将 介绍 用 于 扩展 系统 功能 的 装饰 模式 。 


12.1 图 形 界 面 构件 库 的 设计 


Sunny 软 件 公司 基于 面向 对 得 技术 开发 了 一 套图 形 界 面 构 件 库 VisualComponent， 该 构件 库 提供 
了 大 量 基 本 构件 ， 如 窗 体 、 文 本 框 、 列 表 框 等 ， 由 于 在 使 用 该 构件 库 时 ， 用 户 经 常 要 求 定制 
一 些 特 效 显示 效果 ， 如 带 滚动 条 的 窗 体 、 带 黑色 边框 的 文本 框 、 既 带 滚动 条 又 带 黑色 边框 的 
列表 框 等 等 ， 因 此 经 常 需要 对 该 构件 库 进 行 扩 展 以 增强 其 功能 ， 如 图 12-1 所 示 : 





图 12-1 带 滚 动 条 的 窗 体 示意 图 


如 何 提高 图 形 界 面 构 件 库 性 的 可 扩展 性 并 降低 其 维护 成 本 是 Sunny 公 司 开发 人 员 必 须 面 对 的 一 
个 问题 。 


Sunny 软 件 公司 的 开发 人 员 针 对 上 述 要 求 ， 提 出 了 一 个 基于 继承 复 用 的 初始 设计 方案 ， 其 基本 
结构 如 图 12-2 所 示 : 
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+ display () :void 
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+ display () :void ||+ display () :void ||+ display () :void | |+ display () :void ||+ display () void ||+ display () : void 
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ScrollBarAndBlackBorderTexiBox ScrollBarAndBlackBorderListBox| 
+ display () :void + display () :void + display () :void 


图 12-2 图 形 界面 构件 库 初始 设计 方案 


| ScrollBarWindow BlackBorderWindow 


ScrollBarListBox [| BlackBorderListBox | 
|| 






























图 12-2 中 ， 在 抽象 类 Component 中 声明 了 抽象 方法 display()， 其 子 类 Window、TextBox 等 实现 了 
display() 方 法 ， 可 以 显示 最 简单 的 控件 ， 再 通过 它们 的 子 类 来 对 功能 进行 扩展 ， 例 如 ， 在 
Window 的 子 类 ScrollBarWindow、BlackBorderWindow 中 对 Window 中 的 display0) 方 法 进行 扩 

展 ， 分 别 实 现 带 滚动 条 和 带 黑 色 边 框 的 窗 体 。 仔 细 分 析 该 设计 方案 ， 我 们 不 难 发 现存 在 如 下 
几 个 问题 : 


(1) 系统 扩展 麻烦 ， 在 某 些 编程 语言 中 无 法 实现 。 如 果 用 户 需要 一 个 既 带 滚动 条 又 带 黑色 边框 
的 窗 体 ， 在 图 12-2 中 通过 增加 了 一 个 新 的 类 ScrollBarAndBlackBorderWindow 来 实现 ， 该 类 既 作 
为 ScrollBarWindow 的 子 类 ， 又 作为 BlackBorderWindow 的 子 类 ; 但 现在 很 多 面向 对 象 编程 语 
言 ， 如 Java、C# 等 都 不 支持 多 重 类 继承 ， 因 此 在 这 些 语言 中 无 法 通过 继承 来 实现 对 来 自 多 个 
父 类 的 方法 的 重用 。 此 外 ， 如 果 还 需要 扩展 一 项 功能 ， 例 如 增加 一 个 透明 窗 体 类 
TransparentWindow， 它 是 Window 类 的 子 类 ， 可 以 将 一 个 窗 体 设 置 为 透明 窗 体 ， 现 在 需要 一 个 
同时 拥有 三 项 功能 〈 带 滚动 条 、 带 黑色 边框 、 透 明 ) 的 窗 体 ， 必 须 再 增加 一 个 类 作为 三 个 窗 
体 类 的 子 类 ， 这 同样 在 Java 等 语言 中 无 法 实现 。 系 统 在 扩展 时 非常 麻烦 ， 有 时 候 甚 至 无 法 实 
现 。 


(2) 代 码 重 复 。 从 图 12-2 中 我 们 可 以 看 出 ， 不 只 是 窗 体 需要 设置 滚动 条 ， 文 本 框 、 列 表 框 等 都 
需要 设置 滚动 条 ， 因 此 在 ScrollBarWindow、ScrollBarTextBox 和 ScrollBarListBox 等 类 中 都 包含 
用 于 增加 滚动 条 的 方法 setScrollBar()， 该 方法 的 具体 实现 过 程 基本 相同 ， 代 码 重 复 ， 不 利于 对 
系统 进行 修改 和 维护 。 


(3) 系统 庞大 ， 类 的 数目 非常 多 。 如 果 增 加 新 的 控件 或 者 新 的 扩展 功能 系统 都 需要 增加 大 量 的 
具体 类 ， 这 将 导致 系统 变 得 非常 庞大 。 在 图 12-2 中 ，3 种 基本 控件 和 2 种 扩展 方式 需要 定义 9 个 
具体 类 ; 如 果 再 增加 一 个 基本 控件 还 需要 增加 3 个 具体 类 ; 增加 一 种 扩展 方式 则 需要 增加 更 多 
的 类 ， 如 果 存 在 3 种 扩展 方式 ， 对 于 每 一 个 控件 而 言 ， 需 要 增加 7 个 具体 类 ， 因 为 这 3 种 扩展 方 
式 存 在 7 种 组 合 关系 (大 家 自己 分 析 为 什么 需要 7 个 类 ? ) 。 


总 之 ， 图 12-2 不 是 一 个 好 的 设计 方案 ， 怎 么 办 ? 如 何 让 系统 中 的 类 可 以 进行 扩展 但 是 又 不 会 导 
致 类 数目 的 急剧 增加 ? 不 用 着 急 ， 让 我 们 先 来 分 析 为 什么 这 个 设计 方案 会 存在 如 此 多 的 问 

题 。 根 本 原因 在 于 复 用 机 制 的 不 合理 ， 图 12-2 采 用 了 继承 复 用 ， 例 如 在 ScrollBarWindow 中 需 
要 复 用 Window 类 中 定义 的 display(0) 方 法 ， 同 时 又 增加 新 的 方法 setScrollBar() ，ScrollBarTextBox 
和 ScrollBarListBox 都 必须 做 类 似 的 处 理 ， 在 复 用 父 类 的 方法 后 再 增加 新 的 方法 来 扩展 功能 。 
根据 “合成 复 用 原则 ”， 在 实现 功能 复 用 时 ， 我 们 要 多 用 关联 ， 少 用 继承 ， 因 此 我 们 可 以 换个 角 
度 来 考虑 ， 将 setScrollBar() 方 法 抽取 出 来 ， 封 装 在 一 个 独立 的 类 中 ， 在 这 个 类 中 定义 一 个 
Component 类 型 的 对 象 ， 通 过 调用 Component 的 display() 方 法 来 显示 最 基本 的 构件 ， 同 时 再 通过 
setScrollBar() 方 法 对 基本 构件 的 功能 进行 增强 。 由 于 Window、ListBox 和 TextBox 都 是 
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Component 的 子 类 ， 根 据 * 里 色 代 换 原 则 >， 程序 在 运行 时 ， 我 们 只 要 向 这 个 独立 的 类 中 注入 具 
体 的 Component 子 类 的 对 象 即 可 实现 功能 的 扩展 。 这 个 独立 的 类 一 般 称 为 装饰 器 (Decorator) 或 
装饰 类 ， 顾 名 思 义 ， 它 的 作用 就 是 对 原 有 对 象 进 行 装饰 ， 通 过 装饰 来 扩展 原 有 对 象 的 功能 。 


装饰 类 的 引入 将 大 大 简化 本 系统 的 设计 ， 它 也 是 装饰 模式 的 核心 ， 下 面 让 我 们 正式 进入 装饰 
模式 的 学 习 。 
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12.2 装饰 模式 概述 

装饰 模式 可 以 在 不 改变 一 个 对 象 本 身 功 能 的 基础 上 给 对 象 增 加 额外 的 新 行为 ， 在 现实 生活 
中 ， 这 种 情况 也 到 处 存在 ， 例 如 一 张 照 片 ， 我 们 可 以 不 改变 照片 本 身 ， 给 它 增 加 一 个 相框 ， 
使 得 它 具 有 防潮 的 功能 ， 而 且 用 户 可 以 根据 需要 给 它 增 加 不 同类 型 的 相框 ， 其 至 可 以 在 一 个 
小 相框 的 外 面 再 套 一 个 大 相框 。 

装饰 模式 是 一 种 用 于 替代 继承 的 技术 ， 它 通过 一 种 无 须 定义 子 类 的 方式 来 给 对 象 动态 增加 职 
责 ， 使 用 对 象 之 间 的 关联 关系 取代 类 之 间 的 继承 关系 。 在 装饰 模式 中 引入 了 装饰 类 ， 在 装饰 
类 中 既 可 以 调用 待 装饰 的 原 有 类 的 方法 ， 还 可 以 增加 新 的 方法 ， 以 扩充 原 有 类 的 功能 。 
装饰 模式 定义 如 下 : 


装饰 模式 (Decorator Pattern) : 动态 地 给 一 个 对 象 增 加 一 些 额 外 的 职责 ， 就 增加 对 象 功 能 来 说 ， 
装饰 模式 比 生成 子 类 实现 更 为 灵活 。 装 饰 模式 是 一 种 对 象 结构 型 模式 。 


在 装饰 模式 中 ， 为 了 让 系统 具有 更 好 的 灵活 性 和 可 扩展 性 ， 我 们 通常 会 定义 一 个 抽象 装饰 
类 ， 而 将 具体 的 装饰 类 作为 它 的 子 类 ， 装 饰 模式 结构 如 图 12-3 所 示 : 


Component 


+ Operation () 
AA 



















ConcreteComponent 
+ Operation () 


component.operation(); 


ConcreteDecoratorA 
- addedState : 
+ Operation () 


-|+ operation () 
Pa 






ConcreteDecoratorB 


.+ operation () 
“|+ addedBehavior () 















Fa | 
‘ 


super.operation(); 
addedBehavior(). 
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图 12-3 装饰 模式 结构 图 
在 装饰 模式 结构 图 中 包含 如 下 几 个 角色 : 


e Component (抽象 构件 ) : 它 是 具体 构件 和 抽象 装饰 类 的 共同 父 类 ， 声 明了 在 具体 构件 中 实 
现 的 业务 方法 ， 它 的 引入 可 以 使 客户 端 以 一 致 的 方式 处 理 未 被 装饰 的 对 象 以 及 装饰 之 后 的 对 
象 ， 实 现 客户 端的 透明 操作 。 


e@ ConcreteComponent (具体 构件 ) : 它 是 抽象 构件 类 的 子 类 ， 用 于 定义 具体 的 构件 对 象 ， 实 
现 了 在 抽象 构件 中 声明 的 方法 ， 装 饰 器 可 以 给 它 增 加 额外 的 职责 (方法 ) 。 


e@ Decorator (抽象 装饰 类 ) : 它 也 是 抽象 构件 类 的 子 类 ， 用 于 给 具体 构件 增加 职责 ， 但 是 具体 
民 责 在 其 子 类 中 实现 。 它 维护 一 个 指向 抽象 构件 对 象 的 引用 ， 通 过 该 引用 可 以 调用 装饰 之 前 
构件 对 象 的 方法 ， 并 通过 其 子 类 扩展 该 方法 ， 以 达到 装饰 的 目的 。 


e@ ConcreteDecorator ( 具体 装饰 类 ) : 它 是 抽象 装饰 类 的 子 类 ， 负 责 向 构件 添加 新 的 职责 。 每 
一 个 具体 装饰 类 都 定义 了 一 些 新 的 行为 ， 它 可 以 调用 在 抽象 装饰 类 中 定义 的 方法 ， 并 可 以 增 

加 新 的 方法 用 以 扩充 对 象 的 行为 。 

由 于 具体 构件 类 和 装饰 类 都 实现 了 相同 的 抽象 构件 接口 ， 因 此 装饰 模式 以 对 客户 透明 的 方式 

动态 地 给 一 个 对 象 附加 上 更 多 的 责任 ， 换 言 之 ， 客 户 端 并 不 会 觉得 对 象 在 装饰 前 和 装饰 后 有 

什么 不 同 。 装 饰 模式 可 以 在 不 需要 创造 更 多 子 类 的 情况 下 ， 将 对 象 的 功能 加 以 扩展 。 

装饰 模式 的 核心 在 于 抽象 装饰 类 的 设计 ， 其 典型 代码 如 下 所 示 : 


class Decorator implements Component 


{ 
private Component component; // 维 持 一 个 对 抽象 构件 对 象 的 引用 
public Decorator(Component component )  // 注 入 一 个 抽象 构件 类 型 的 对 
{ 
this.component=component,; 
} 
public void operation() 
{ 
component.operation(); // 调 用 原 有 业务 方法 
} 
} 


在 抽象 装饰 类 Decorator 中 定义 了 一 个 Component 类 型 的 对 象 component， 维 持 一 个 对 抽象 构件 
对 象 的 引用 ， 并 可 以 通过 构造 方法 或 Setter 方 法 将 一 个 Component 类 型 的 对 象 注 入 进来 ， 同 时 
由 于 Decorator 类 实现 了 抽象 构件 Component 接 口 ， 因 此 需要 实现 在 其 中 声明 的 业务 方法 
operation() ， 需 要 注意 的 是 在 Decorator 中 并 未 丨 正 实现 operation() 方 法 ， 而 只 是 调用 原 有 
component 对 象 的 operation() 方 法 ， 它 没有 真正 实施 装饰 ， 而 是 提供 一 个 统一 的 接口 ， 将 具体 装 
饰 过 程 交 给 予 类 完成 。 


在 Decorator 的 子 类 即 具 体 装 饰 类 中 将 继承 operation() 方 法 并 根据 需要 进行 扩展 ， 典 型 的 具体 装 
饰 类 代码 如 下 : 


class ConcreteDecorator extends Decorator 


{ 


public ConcreteDecorator(Component component) 


t 


super (component ); 
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public void operation() 


{ 
super.operation(); // 调 用 原 有 业务 方法 
addedBehavior(); // 调 用 新 增 业 务 方法 
} 
// 新 增 业 务 方法 
public void addedBehavior() 
{ 
} 
} 


在 具体 装饰 类 中 可 以 调用 到 抽象 装饰 类 的 operation() 方 法 ， 同 时 可 以 定义 新 的 业务 方法 ， 如 
addedBehavior() ° 


由 于 在 抽象 装饰 类 Decorator 中 注入 的 是 Component 类 型 的 对 象 ， 因 此 我 们 可 以 将 一 个 具体 构件 
对 象 注入 其 中 ， 再 通过 具体 装饰 类 来 进行 装饰 ; 此 外 ， 我 们 还 可 以 将 一 个 已 经 装饰 过 的 
Decorator 子 类 的 对 象 再 注入 其 中 进行 多 次 装饰 ， 从 而 对 原 有 功能 的 多 次 扩展 。 

思考 


能 否 在 装饰 模式 中 找 出 两 个 独立 变化 的 维度 ? 试 比较 装饰 模式 和 桥接 模式 的 相同 之 处 和 
不 同 之 处 ? 
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12.3 完整 解决 方案 


为 了 让 系统 具有 更 好 的 灵活 性 和 可 扩展 性 ， 克 服 继承 复 用 所 带 来 的 问题 ，Sunny 公 司 开 发 人 员 
使 用 装饰 模式 来 重 构图 形 界面 构件 库 的 设计 ， 其 中 部 分 类 的 基本 结构 如 图 12-4 所 示 : 


Component 
{abstract} 


+ display () : void 
pa a 


A 






















让 
ComponentDecorator 
- Component : Component 


+ ComponentDecorator (Component component) 


+ display () : void + display () 
ScrollBarDecorator 


+ ScrollBarDecorator (Component component) + BlackBorderDecorator ( 

+ display () : void Component component) 

+ setScrollBar () : void + display () :void 
+ SetBlackBorder () :void | 













+ display () : void 


+ display () : void 








: void 









BlackBorderDecorator 








图 12-4 图 形 界 面 构件 库 结 构图 


在 图 12-4 中 ，Component 充 当 抽 象 构件 类 ， 其 子 类 Window、TextBox、ListBox 充 当 具 体 构件 
类 ，Component 类 的 另 一 个 子 类 ComponentDecorator 充 当 抽象 装饰 类 ，ComponentDecorator 的 
子 类 ScrollBarDecorator 和 BlackBorderDecorator 充 当 具 体 装 饰 类 。 完 整 代码 如 下 所 示 : 


// 抽 象 界 面 构件 类 : 抽象 构件 类 ， 为 了 突出 与 模式 相关 的 核心 代码 ， 对 原 有 控件 代码 进行 了 大 
abstract class Component 


{ 


} 


// 窗 体 类 : 具体 构件 类 
class Window extends Component 


public abstract void display(); 


{ 
public void display() 
{ 
System.out.println(" 显 示 窗 体 1")， 
} 
} 


// 文 本 框 类 : 具体 构件 类 
class TextBox extends Component 


{ 
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public void display() 
t 


} 


System.out.println(" 显 示 文本 框 1")， 


} 


// 列 表 框 类 : 具体 构件 类 
class ListBox extends Component 


{ 
public void display() 
{ 
System.out.println(" 显 示 列 表 框 ! ")， 
} 
} 


// 构 件 装饰 类 : 抽象 装饰 类 
class ComponentDecorator extends Component 


{ 
private Component component; // 维 持 对 抽象 构件 类 型 对 象 的 引用 
public ComponentDecorator(Component component) // 注 入 抽象 构件 . 
{ 
this.component = component; 
} 
public void display() 
{ 
component.display(); 
} 
} 


// 滚 动 条 装饰 类 : 具体 装饰 类 
class ScrollBarDecorator extends ComponentDecorator 


{ 


public ScrollBarDecorator(Component component) 


{ 
super (component ) ; 
} 
public void display() 
{ 
this.setScrollBar(); 
super.display(); 
} 
public void setScrollBar() 
{ 
System.out.println(" 为 构件 增加 滚动 条 |! "); 
} 


} 


// 黑 色 边 框 装饰 类 : 具体 装饰 类 
class BlackBorderDecorator extends ComponentDecorator 
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{ 
public BlackBorderDecorator(Component component) 
{ 
super (component); 
} 
public void display() 
{ 
this.setBlackBorder(); 
super.display(); 
} 
public void setBlackBorder() 
{ 
System.out.println(" 为 构件 增加 黑色 边框 1"); 
} 
} 


编写 如 下 客户 端 测 试 代 码 : 


class Client 
{ 
public Static void main(String args[]) 
{ 
Component component,componentSB; // 使 用 抽象 构件 定义 
component = new Window(); // 定 义 具 体 构 件 
componentSB = new ScrollBarDecorator(component); // 定 ; 
componentSsB.display(); 


| 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 
为 构件 增加 滚动 条 ! 


显示 窗 体 ! 


在 客户 端 代码 中 ， 我 们 先 定义 了 一 个 Window 类 型 的 具体 构件 对 象 component， 然 后 将 
component 作 为 构造 函数 的 参数 注入 到 具体 装饰 类 ScrollBarDecorator 中 ， 得 到 一 个 装饰 之 后 对 
象 componentSB， 再 调用 componentSB 的 display() 方 法 后 将 得 到 一 个 有 滚动 条 的 窗 体 。 如 果 我 们 
希望 得 到 一 个 既 有 滚动 条 又 有 黑色 边框 的 窗 体 ， 不 需要 对 原 有 类 库 进行 任何 修改 ， 只 需 将 客 
户 端 代码 修改 为 如 下 所 示 : 


class Client 


{ 
public static void main(String args[]) 
{ 
Component component,componentSB,componentBB; // 全 部 使 用 
component = new Window( ); 
componentSB = new ScrollBarDecorator(component); 
componentBB = new BlackBorderDecorator(componentSB); ， 
componentBB .display(); 
} 
} 
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编译 并 运行 程序 ， 输 出 结果 如 下 : 


为 构件 增加 黑色 边框 ! 
为 构件 增加 滚动 条 ! 
显示 窗 体 ! 


我 们 可 以 将 装饰 了 一 次 之 后 的 component SB 对象 注入 另 一 个 装饰 类 BlackBorderDecorator 中 实现 
第 二 次 装饰 ， 得 到 一 个 经 过 两 次 装饰 的 对 象 componentBB， 再 调用 componentBB 的 display() 方 
法 即 可 得 到 一 个 既 有 滚动 条 又 有 黑色 边框 的 窗 体 。 


如 果 需 要 在 原 有 系统 中 增加 一 个 新 的 具体 构件 类 或 者 新 的 具体 装饰 类 ， 无 须 修 改 现 有 类 库 代 
码 ， 只 需 将 它们 分 别 作 为 抽象 构件 类 或 者 抽象 装饰 类 的 子 类 即 可 。 与 图 12-2 所 示 的 继承 结构 相 
比 ， 使 用 装饰 模式 之 后 将 大 大 减少 了 子 类 的 个 数 ， 让 系统 扩展 起 来 更 加 方便 ， 而 且 更 容易 维 
护 ， 是 取代 继承 复 用 的 有 效 方式 之 一 。 
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12.4 透明 装饰 模式 与 半 透 明 装 饰 模式 


装饰 模式 虽 好 ， 但 存在 一 个 问题 。 如 果 客 户 端 希 望 单 独 调用 具体 装饰 类 新 增 的 方法 ， 而 不 想 
通过 抽象 构件 中 声明 的 方法 来 调用 新 增 方法 时 将 遇 到 一 些 麻烦 ， 我 们 通过 一 个 实例 来 对 这 种 
情况 加 以 说 明 : 在 Sunny 软 件 公司 开 发 的 Sunny OA 系统 中 ， 采 购 单 (PurchaseRequesD 和 请 假 条 
(LeaveRequesb) 等 文件 (Documenb 对 象 都 具有 显示 功能 ， 现 在 要 为 其 增加 审批 、 删 除 等 功能 ， 
使 用 装饰 模式 进行 设计 。 


我 们 使 用 装饰 模式 可 以 得 到 如 图 12-5 所 示 结 构图 : 


Document 


+ dislpay () : void 












PurchaseRequest 


+ display () : void 





LeaveRequest 
+ display () : void 












+ Decorator (Document document) 
+ display () :void 
















+ Approver (Document document) 
+ approve () 


+ Deleter (Document document) 
+ delete () 
















: void :void 


图 12-5 文 件 对 象 功 能 增加 实例 结构 图 


在 图 12-5 中 ，Document 充 当 抽 象 构 件 类 ，PurchaseRequest 和 LeaveRequest 充 当 具 体 构件 类 ， 
Decorator 充 当 抽 象 装饰 类 ，Approver 和 Deleter 充 当 具 体 装 饰 类 。 其 中 Decorator 类 和 Approver 类 
的 示例 代码 如 下 所 示 : 


// 抽 象 装饰 类 
class Decorator implements Document 


{ 


private Document  _ document ; 


public Decorator(Document  _ document ) 


上 
} 


public void display() 


this. document = document; 
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{ 
document .display(); 
} 
} 
// 具 体 装 饰 类 


class Approver extends Decorator 


public Approver (Document document) 


{ 
super(document ) ; 
System.out.println(" 增 加 审批 功能 ! ")， 
} 
public void approve() 
{ 
System.out.println(" 审 批文 件 1"); 
} 


} 


大 家 注意 ，Approver 类 继承 了 抽象 装饰 类 Decorator 的 display0) 方 法 ， 同 时 新 增 了 业务 方法 
approve(O)， 但 这 两 个 方法 是 独立 的 ， 没 有 任何 调用 关系 。 如 果 客 户 端 需要 分 别 调用 这 两 个 方 
法 ， 代 码 片 段 如 下 所 示 : 


Document doc; // 使 用 抽象 构件 类 型 定义 
doc = new PurchaseRequest(); 
Approver newDoc; // 使 用 具体 装饰 类 型 定义 
newDoc = new Approver(doc); 
newDoc.display( );// 调 用 原 有 业务 方法 
newDoc.approve( ) ;// 调 用 新 增 业 务 方法 


如 果 newDoc 也 使 用 Document 类 型 来 定义 ， 将 导致 客户 端 无 法 调用 新 增 业 务 方法 approve() ， 
为 在 抽象 构件 类 Document 中 没有 对 approve() 方 法 的 声明 。 也 就 是 说 ， 在 客户 端 无 法 统一 对 待 
装饰 之 前 的 具体 构件 对 象 和 装饰 之 后 的 构件 对 象 。 


在 实际 使 用 过 程 中 ， 由 于 新 增 行为 可 能 需要 单独 调用 ， 因 此 这 种 形式 的 装饰 模式 也 经 常 出 
现 ， 这 种 装饰 模式 被 称 为 半 透 明 (Semi-transparenb) 装 饰 模式 ， 而 标准 的 装饰 模式 是 透明 
(Transparent) 装 饰 模式 。 下 面 我 们 对 这 两 种 装饰 模式 进行 较为 详细 的 介绍 : 


(D) 透 明 装饰 模式 


在 透明 装饰 模式 中 ， 要 求 客户 端 完全 针对 抽象 编程 ， 装 饰 模式 的 透明 性 要 求 客户 端 程序 不 应 
该 将 对 象 声 明 为 具体 构件 类 型 或 具体 装饰 类 型 ， 而 应 该 全 部 声明 为 抽象 构件 类 型 。 对 于 客户 
端 而 言 ， 具 体 构件 对 象 和 具体 装饰 对 象 没有 任何 区 别 。 也 就 是 应 该 使 用 如 下 代码 : 


Component  c，c1， // 使 用 抽象 构件 类 型 定义 对 象 
c= new ConcreteComponent(); 
c1 = new ConcreteDecorator (c); 

而 不 应 该 使 用 如 下 代码 : 
ConcreteComponent c; // 使 用 具体 构件 类 型 定义 对 象 
c = new ConcreteComponent(); 

或 
ConcreteDecorator ci; // 使 用 具体 装饰 类 型 定义 对 外 
cli = new ConcreteDecorator(c); 
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在 12.3 节 图 形 界面 构件 库 的 设计 方案 中 使 用 的 就 是 透明 装饰 模式 ， 在 客户 端 中 存在 如 下 代码 片 


段 : 


Component component,componentSB,componentBB; // 全 部 使 用 抽象 构件 定义 
component = new Window(); 

componentSB = new ScrollBarDecorator (component); 

componentBB = new BlackBorderDecorator (componentSsB ); 
componentBB. display(); 


使 用 抽象 构件 类 型 Component 定 义 全 部 具体 构件 对 象 和 具体 装饰 对 象 ， 客 户 端 可 以 一 致 地 使 用 
这 些 对 象 ， 因 此 符合 透明 装饰 模式 的 要 求 。 


透明 装饰 模式 可 以 让 客户 端 透 明 地 使 用 装饰 之 前 的 对 象 和 装饰 之 后 的 对 象 ， 无 须 关 心 它 们 的 
区 别 ， 此 外 ， 还 可 以 对 一 个 已 装饰 过 的 对 象 进 行 多 次 装饰 ， 得 到 更 为 复杂 、 功 能 更 为 强大 的 
对 象 。 在 实现 透明 装饰 模式 时 ， 要 求 具 体 装 饰 类 的 operation() 方 法 履 盖 抽象 装饰 类 的 operation() 
方法 ， 除 了 调用 原 有 对 象 的 operation() 外 还 需要 调用 新 增 的 addedBehavior() 方 法 来 增加 新 行 
pa 


(2) 半 透明 装饰 模式 


透明 装饰 模式 的 设计 难度 较 大 ， 而 且 有 时 我 们 需要 单独 调用 新 增 的 业务 方法 。 为 了 能 够 调用 
到 新 增 方法 ， 我 们 不 得 不 用 具体 装饰 类 型 来 定义 装饰 之 后 的 对 象 ， 而 具体 构件 类 型 还 是 可 以 
使 用 抽象 构件 类 型 来 定义 ， 这 种 装饰 模式 即 为 半 透 明 装 饰 模式 ， 也 就 是 说 ， 对 于 客户 端 而 
言 ， 具 体 构件 类 型 无 须 关心 ， 是 透明 的 ; 但 是 具体 装饰 类 型 必须 指定 ， 这 是 不 透明 的 。 如 本 
节 前 面 所 提 到 的 文件 对 象 功能 增加 实例 ， 为 了 能 够 调用 到 在 Approver 中 新 增 方 法 approve()， 客 
户 端 代码 片段 如 下 所 示 : 


Document doc; // 使 用 抽象 构件 类 型 定义 
doc = new PurchaseRequest ( ) ， 
Approver newDoc; // 使 用 具体 装饰 类 型 定义 
newDoc = new Approver(doc ) ; 


ie 


半 透 明 装饰 模式 可 以 给 系统 带 来 更 多 的 灵活 性 ， 设 计 相 对 简单 ， 使 用 起 来 也 非常 方便 ; 但 是 
其 最 大 的 缺点 在 于 不 能 实现 对 同一 个 对 象 的 多 次 装饰 ， 而 且 客 户 端 需要 有 区 别 地 对 待 装饰 之 
前 的 对 象 和 装饰 之 后 的 对 象 。 在 实现 半 透 明 的 装饰 模式 时 ， 我 们 只 需 在 具体 装饰 类 中 增加 一 
个 独立 的 addedBehavior() 方 法 来 封装 相应 的 业务 处 理 ， 由 于 客户 端 使 用 具体 装饰 类 型 来 定义 装 
饰 后 的 对 象 ， 因 此 可 以 单独 调用 addedBehavior() 方 法 来 扩展 系统 功能 。 


思 
为 什么 半 透 明 装 饰 模式 不 能 实现 对 同一 个 对 象 的 多 次 装饰 ? 

12.5 装饰 模式 注意 事项 

在 使 用 装饰 模式 时 ， 通 常 我 们 需要 注意 以 下 几 个 问题 : 

(1) 尽量 保持 装饰 类 的 接口 与 被 装饰 类 的 接口 相同 » 这 样 » 对 于 客户 端 而 言 5 无 论 是 装饰 之 前 
的 对 象 还 是 装饰 之 后 的 对 象 都 可 以 一 致 对 待 。 这 也 就 是 说 ， 在 可 能 的 情况 下 ， 我 们 应 该 尽量 
使 用 透明 装饰 模式 。 


(2) 尽量 保持 具体 构件 类 ConcreteComponent 是 一 个 “ 轻 ” 类 ， 也 就 是 说 不 要 把 太 多 的 行为 放 在 具 
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体 构件 类 中 ， 我 们 可 以 通过 装饰 类 对 其 进行 扩展 。 


(3) 如 果 只 有 一 个 具体 构件 类 ， 那 么 抽象 装饰 类 可 以 作为 该 具体 构件 类 的 直接 子 类 。 如 图 12-6 
所 示 : 













ConcreteComponent 
+ operation () 
A 











Decorator 


+ Decorator (ConcreteComponent component) 
+ operation () 


> 









ConcreteDecoratorB 


+ operation () 
+ addedBehavior () 


ConcreteDecoratorA 
- addedState : 


+ operation () 









图 12-6 没有 抽象 构件 类 的 装饰 模式 

12.6 装饰 模式 总 结 

装饰 模式 降低 了 系统 的 耦合 度 ， 可 以 动态 增加 或 删除 对 象 的 职责 ， 并 使 得 需要 装饰 的 具体 构 
件 类 和 具体 装饰 类 可 以 独立 变化 ， 以 便 增加 新 的 具体 构件 类 和 具体 装饰 类 。 在 软件 开发 中 ， 
装饰 模式 应 用 较为 广泛 ， 例 如 在 JavaIO 中 的 输入 流 和 输出 流 的 设计 、javax.swing 包 中 一 些 图 形 
界面 构件 功能 的 增强 等 地 方 都 运用 了 装饰 模式 。 

1. 主 要 优点 

装饰 模式 的 主要 优点 如 下 : 

(1) 对 于 扩展 一 个 对 象 的 功能 ， 装 饰 模式 比 继承 更 加 灵活 性 ， 不 会 导致 类 的 个 数 急剧 增加 。 


(2) 可 以 通过 一 种 动态 的 方式 来 扩展 一 个 对 象 的 功能 ， 通 过 配置 文件 可 以 在 运行 时 选择 不 同 的 
具体 装饰 类 ， 从 而 实现 不 同 的 行为 。 


(3) 可 以 对 一 个 对 象 进行 多 次 装饰 ， 通 过 使 用 不 同 的 具体 装饰 类 以 及 这 些 装饰 类 的 排列 组 合 ， 
可 以 创造 出 很 多 不 同行 为 的 组 合 ， 得 到 功能 更 为 强大 的 对 象 。 


(4) 具体 构件 类 与 具体 装饰 类 可 以 独立 变化 ， 用 户 可 以 根据 需要 增加 新 的 具体 构件 类 和 具体 装 
饰 类 ， 原 有 类 库 代 码 无 须 改变 ， 符 合 “ 开 闭 原则 ”。 
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2. 主 要 缺点 
装饰 模式 的 主要 缺点 如 下 : 

(1) 使 用 装饰 模式 进行 系统 设计 时 将 产生 很 多 小 对 象 ， 这 些 对 象 的 区 别 在 于 它们 之 间 相 互 连 接 
的 方式 有 所 不 同 ， 而 不 是 它们 的 类 或 者 属性 值 有 所 不 同 ， 大 量 小 对 象 的 产生 势必 会 占用 更 多 
的 系统 资源 ， 在 一 定 程序 上 影响 程序 的 性 能 。 


(2) 装饰 模式 提供 了 一 种 比 继承 更 加 灵活 机 动 的 解决 方案 ， 但 同时 也 意味 着 比 继承 更 加 荔 于 出 
错 ， 排 错 也 很 困难 ， 对 于 多 次 装饰 的 对 象 ， 调 试 时 寻找 错误 可 能 需要 逐 级 排查 ， 较 为 繁琐 。 


3. 适 用 场景 
在 以 下 情况 下 可 以 考虑 使 用 装饰 模式 : 
(1) 在 不 影响 其 他 对 象 的 情况 下 ， 以 动态 、 透 明 的 方式 给 单个 对 象 添 加 职责 。 
(2) 当 不 能 采用 继承 的 方式 对 系统 进行 扩展 或 者 采用 继承 不 利于 系统 扩展 和 维护 时 可 以 使 用 装 
饰 模式 。 不 能 采用 继承 的 情况 主要 有 两 类 : 第 一 类 是 系统 中 存在 大 量 独 立 的 扩展 ， 为 支持 每 
一 种 扩展 或 者 扩展 之 间 的 组 合 将 产生 大 量 的 子 类 ， 使 得 子 类 数目 呈 爆 炸 性 增长 ; 第 二 类 是 因 
为 类 已 定义 为 不 能 被 继承 (如 Java 语 言 中 的 final 类 ) 。 
练习 
Sunny 软 件 公司 欲 开 发 了 一 个 数据 加 密 模 块 ， 可 以 对 字符 串 进 行 加 密 。 最 简单 的 加 密 算 法 
通过 对 字母 进行 移 位 来 实现 ， 同 时 还 提供 了 稍 复杂 的 逆向 输出 加 审 ， 还 提供 了 更 为 高 级 
的 求 模 加 密 。 用 户 先 使 用 最 简单 的 加 密 算 法 对 字符 串 进 行 加 密 ， 如 果 觉 得 还 不 够 可 以 对 


加 密 之 后 的 结果 使 用 其 他 加 密 算 法 进行 二 次 加 审 ， 当 然 也 可 以 进行 第 三 次 加 审 。 试 使 用 
装饰 模式 设计 该 多 重 加 密 系 统 。 
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外 观 模式 -Facade Pattern 


外 观 模式 -Facade Pattern 【学 习 难 度 : 砍 交 六 六 六 ， 使 用 频 府 : 次 六 交友 友 】 


e@ 外 观 模式 -Facade Pattern 
o 深入 浅 出 外 观 模式 (一 ) 
o 深入 浅 出 外 观 模式 (二 ) 
o 深入 浅 出 外 观 模式 (三 ) 


200 


深入 浅 出 外 观 模 式 (一 ) 


深入 浅 出 外 观 模式 (一 ) 
深入 浅 出 外 观 模式 (一 ) 


外 观 模式 是 一 种 使 用 频率 非常 高 的 结构 型 设计 模式 ， 它 通过 引入 一 个 外 观 角色 来 简化 客户 端 
与 子 系统 之 间 的 交互 ， 为 复杂 的 子 系统 调用 提供 一 个 统一 的 入 口 ， 降 低 子 系统 与 客户 端的 耦 
合 度 ， 且 客户 端 调用 非常 方便 。 
1， 外观 模 式 概述 

不 知道 大 家 有 没有 比较 过 自己 泡 茶 和 去 茶馆 喝 茶 的 区 别 ， 如 果 是 自己 泡 茶 需要 自行 准备 茶 
叶 、 茶 具 和 开水 ， 如 图 1(A) 所 示 ， 而 去 茶馆 喝 茶 ， 最 简单 的 方式 就 是 跟 茶 馆 服 务 员 说 想 要 一 杯 
什么 样 的 茶 ， 是 铁 观 音 、 怕 螺 春 还 是 西湖 龙井 ?3 正 因为 茶馆 有 服务 员 ， 顾 客 无 须 直接 和 茶 
叶 、 茶 具 、 开 水 等 交互 ， 整 个 泡 茶 过 程 由 服务 员 来 完成 ， 顾 客 只 需 与 服务 员 交互 即 可 ， 整 个 


过 程 非常 简单 省 事 ， 如 图 1(B) 所 示 。 











(A) 自己 泡 茶 (B) 去 茶馆 喝 茶 
图 1 两 种 喝 茶 方式 示意 图 


在 软件 开发 中 ， 有 时 候 为 了 完成 一 项 较为 复杂 的 功能 ， 一 个 客户 类 需要 和 多 个 业务 类 交互 ， 

而 这 些 需 要 交互 的 业务 类 经 常会 作为 一 个 整体 出 现 ， 由 于 涉及 到 的 类 比较 多 ， 导 致使 用 时 代 

码 较 为 复杂 ， 此 时 ， 特 别 需要 一 个 类 似 服务 员 一 样 的 角色 ， 由 它 来 负责 和 多 个 业务 类 进行 交 

互 ， 而 客户 类 只 需 与 该 类 交互 。 外 观 模式 通过 引入 一 个 新 的 外 观 类 (Facade) 来 实现 该 功能 ， 外 
观 类 充当 了 软件 系统 中 的 “服务 员 ”， 它 为 多 个 业务 类 的 调用 提供 了 一 个 统一 的 入 口 ， 简 化 了 类 
与 类 之 间 的 交互 。 在 外 观 模式 中 ， 那 些 需 要 交互 的 业务 类 被 称 为 子 系统 (Subsystem)。 如 果 没 

有 外 观 类 ， 那 么 每 个 客户 类 需要 和 多 个 子 系统 之 间 进 行 复杂 的 交互 ， 系 统 的 耦合 度 将 很 大 ， 

如 图 2(A) 所 示 ; 而 引入 外 观 类 之 后 ， 客 户 类 只 需要 直接 与 外 观 类 交互 ， 客 户 类 与 子 系统 之 问 原 
有 的 复杂 引用 关系 由 外 观 类 来 实现 ， 从 而 降低 了 系统 的 耦合 度 ， 如 图 2(B) 所 示 。 
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Subsystem 


(A) (B) 


图 2 外 观 模式 示意 图 


外 观 模式 中 ， 一 个 子 系统 的 外 部 与 其 内 部 的 通信 通 
类 与 子 系统 的 内 部 复杂 性 分 隔 开 ， 使 得 客户 类 只 需 
内 部 的 很 多 对 象 打交道 。 

外 观 模式 定义 如 下 : 外 观 模式 : 为 子 系统 中 的 一 组 接口 提供 一 个 统一 的 入 口 。 外 观 模式 定义 
了 一 个 高 层 接口 ， 这 个 接口 使 得 这 一 子 系统 更 加 容易 使 用 。 Facade Pattern: Provide a unified 
interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the 
subsystem easier to use. 


过 一 个 统一 的 外 观 类 进行 ， 外 观 类 将 客户 
要 与 外 观 角 色 打 交道 ， 而 不 需要 与 子 系统 


外 观 模 式 又 称 为 门面 模式 ， 它 是 一 种 对 象 结 构 型 模式 。 外 观 模 式 是 迪 米 特 法 则 的 一 种 具体 实 
现 ， 通 过 引入 一 个 新 的 外 观 角 色 可 以 降低 原 有 系统 的 复杂 度 ， 同 时 降低 客户 类 与 子 系统 的 耦 
合 度 。 


1. 外 观 模式 结构 与 实现 2.1 模式 结构 


外 观 模式 没有 一 个 一 般 化 的 类 图 描述 ， 通 常 使 用 如 图 2(B) 所 示 示 意图 来 表示 外 观 模 式 。 图 3 所 
示 的 类 图 也 可 以 作为 描述 外 观 模式 的 结构 图 : 
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“< 
-i 





图 3 外 观 模式 结构 图 
由 图 3 可 知 ， 外 观 模式 包含 如 下 两 个 角色 : 


(1) Facade (外 观 角色 ) : 在 客户 端 可 以 调用 它 的 方法 ， 在 外 观 角色 中 可 以 知道 相关 的 《一 个 
或 者 多 个 ) 子 系统 的 功能 和 责任 ; 在 正常 情况 下 ， 它 将 所 有 从 客户 端 发 来 的 请 求 委 派 到 相应 
的 子 系统 去 ， 传 递 给 相应 的 子 系统 对 象 处 理 。 


(2) SubSystem ( 子 系统 角色 ) : 在 软件 系统 中 可 以 有 一 个 或 者 多 个 子 系统 角色 ， 每 一 个 子 系统 
可 以 不 是 一 个 单独 的 类 ， 而 是 一 个 类 的 集合 ， 它 实现 子 系统 的 功能 ; 每 一 个 子 系统 都 可 以 被 
客户 端 直接 调用 ， 或 者 被 外 观 角 色调 用 ， 它 处 理由 外 观 类 传 过 来 的 请 求 ; 子 系统 并 不 知道 外 
现 的 存在 ， 对 于 子 系统 而 言 ， 外 现 角色 仅仅 是 另外 一 个 客户 端 而 已 。 


2.2 模式 实现 


外 观 模 式 的 主要 目的 在 于 降低 系统 的 复杂 程度 ， 在 面向 对 象 软件 系统 中 ， 类 与 类 之 间 的 关系 
越 多 ， 不 能 表示 系统 设计 得 越 好 ， 反 而 表示 系统 中 类 之 间 的 耦合 度 太 大 ， 这 样 的 系统 在 维护 
和 修改 时 都 缺乏 灵活 性 ， 因 为 一 个 类 的 改动 会 导致 多 个 类 发 生变 化 ， 而 外 观 模式 的 引入 在 很 
大 程度 上 降低 了 类 与 类 之 间 的 耦合 关系 。 引 入 外 观 模式 之 后 ， 增 加 新 的 子 系统 或 者 移 除 子 系 
统 都 非常 方便 ， 客 户 类 无 须 进 行 修改 〈 或 者 极 少 的 修改 ) ， 只 需要 在 外 观 类 中 增加 或 移 除 对 
子 系 统 的 引用 即 可 。 从 这 一 点 来 说 ， 外观 模 式 在 一 定 程度 上 并 不 符合 开 闭 原则 ， 增 加 新 的 子 
系统 需要 对 原 有 系统 进行 一 定 的 修改 ， 虽 然 这 个 修改 工作 量 不 大 。 


外 观 模式 中 所 指 的 子 系统 是 一 个 广义 的 概念 ， 它 可 以 是 一 个 类 、 一 个 功能 模块 、 系 统 的 一 个 
组 成 部 分 或 者 一 个 完整 的 系统 。 子 系统 类 通常 是 一 些 业 务 类 ， 实 现 了 一 些 具体 的 、 独 立 的 业 
务 功 能 ， 其 典型 代码 如 下 : 


class SubSystemA 


{ 
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public void MethodA( ) 


{ 
// 业 务实 现代 码 
} 
} 
class SubSystemB 
{ 
public void MethodB() 
{ 
// 业 务实 现代 码 
} 
} 
class SubSystemC 
{ 
public void Methodc() 
{ 
// 业 务实 现代 码 
} 
} 


在 引入 外 观 类 之 后 ， 与 子 系统 业务 类 之 间 的 交互 统一 由 外 观 类 来 完成 ， 在 外 观 类 中 通常 存在 
如 下 代码 : 


class Facade 

{ 
private SubSystemA obj1 
private SubSystemB obj2 
private SubSystemC obj3 


new SubSystemA( ); 
new SubSystemB( ) ; 
new SubSystemC(); 


public void Method () 
{ 
obj1.MethodA( ); 
obj2.MethodB( ); 
obj3.MethodCc( ); 


} 

由 于 在 外 观 类 中 维持 了 对 子 系统 对 象 的 引用 ， 客 户 端 可 以 通过 外 观 类 来 间接 调用 子 系统 对 象 
的 业务 方法 ， 而 无 须 与 子 系统 对 象 直 接 交互 。 引 入 外 观 类 后 ， 客 户 端 代 码 变 得 非常 简单 ， 典 
型 代码 如 下 : 


class Program 


{ 
static void Main(string[] args) 
{ 
Facade facade = new Facade(); 
facade.Method( ); 
} 
} 
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深入 泌 出 外 观 模式 (二 ) 


1. 外 观 模式 应 用 实例 
下 面 通过 一 个 应 用 实例 来 进一步 学 习 和 理解 外 观 模式 。 

1， 实例 说 明 
某 软 件 公司 欲 开 发 一 个 可 应 用 于 多 个 软件 的 文件 加 蜜 模块 ， 该 模块 可 以 对 文件 中 的 数据 进行 
加 密 并 将 加 密 之 后 的 数据 存储 在 一 个 新 文件 中 ， 有 具体 的 流程 包括 三 个 部 分 ， 分 别 是 读 取 源 文 
件 、 加 密 、 保 存 加 密 之 后 的 文件 ， 其 中 ， 读 取 文 件 和 保存 文件 使 用 流 来 实现 ， 加 密 操 作 通 过 
求 模 运算 实现 。 这 三 个 操作 相对 独立 ， 为 了 实现 代码 的 独立 重用 ， 让 设计 更 符合 单一 职责 原 
则 ， 这 三 个 操作 的 业务 代码 封装 在 三 个 不 同 的 类 中 。 
现 使 用 外 观 模式 设计 该 文件 加 密 模 块 。 

1， 实例 类 图 


通过 分 析 ， 本 实例 结构 图 如 图 4 所 示 。 


string plainStr = reader.Read(fileNameSrc); 
string encryptStr = cipherEncrypt(plainStr): 
writer.Write(encryptStr,fleNameDes); 





图 4 文件 加 密 模 块 结构 图 

在 图 4 中 ，EncryptFacade 充 当 外 观 类 ，FileReader、CipherMachine 和 FileWriter 充 当 子 系统 类 。 
1. 实例 代码 

(1) FileReader : 文件 读 取 类 ， 充 当 子 系统 类 。 

//FileReader.cs 

using System; 


using System.Text; 
using System.I0， 
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namespace FacadeSample 


{ 
class FileReader 
{ 
public string Read(string fileNameSrc) 
{ 
Console .Write(" 读 取 文 件 ， 获 取 明 文 : ")， 
FileStream fs = null; 
StringBuilder sb = new StringBuilder(); 
try 
{ 
fs = new FileStream(fileNameSrc, FileMode.Open); 
int data; 
while((data = fs.ReadByte())!= -1) 
{ 
sb = sb.Append((char)data); 
fs.Close( ); 
Console.writeLine(sb,.ToString()); 
} 
catch(FileNotFoundException e) 
{ 
Console .WriteLine(" 文 件 不 存在 ! "); 
} 
catch(IOException e) 
{ 
Console,WriteLine(" 文 件 操作 错误 1! ")， 
} 
return sb.ToString(); 
} 
} 
} 


(2) CipherMachine : 数据 加 密 类 ， 充 当 子 系统 类 。 
//CipherMachine.cs 


Using System; 
Using System.Text,; 


namespace FacadeSample 


{ 
class CipherMachine 
{ 
public string Encrypt(string plainText) 
{ 
Console.Write(" 数 据 加 密 ， 将 明文 转换 为 密 文 :")， 
string es = "",， 


char[] chars = plainText.ToCharArray(); 
foreach(char ch in chars) 


{ 
string c = (ch % 7).ToString(); 
es += C) 
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} 
Console.WriteLine(es); 
return es; 


| 


} 

(3) FileWriter : 文件 保存 类 ， 充 当 子 系统 类 。 
//Filewriter.cs 

using System; 


using System.10; 
using System.Text,; 


namespace FacadeSample 


{ 
class Filewriter 
{ 
public void Write(string encryptStr,string fileNameDes) 
{ 
Console.WriteLine(" 保 存 密 文 ， 写 入 文件 。")， 
FileStream fs = null; 
try 
{ 
fs = new FileStream(fileNameDes, FileMode.Create); 
byte[] str = Encoding.Default.GetBytes(encryptStr); 
fs.wWrite(str,o0,str.Length); 
fs.Flush(); 
fs.Close( ); 
} 
catch(FileNotFoundException e) 
Console .WriteLine(" 文 件 不 存在 ! "); 
} 
catch(IOException e) 
{ 
Console.wWriteLine(e.Message); 
Console,WriteLine(" 文 件 操作 错误 ! ")， 
} 
} 
} 
} 


(4) EncryptFacade : 加 密 外 观 类 ， 充 当 外 观 类 。 


// EncryptFacade.cs 
namespace FacadeSample 


{ 


class EncryptFacade 


// 维 持 对 其 他 对 象 的 引用 
private FileReader reader; 
private CipherMachine cipher; 
private Filewriter writer; 
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public EncryptFacade() 


{ 
reader = new FileReader(); 
cipher = new CipherMachine(); 
writer = new FileWwriter(); 

} 


// 调 用 其 他 对 象 的 业务 方法 
public void FileEncrypt(string fileNameSrc, string fileName 


{ 
string plainStr = reader.Read(fileNameSrc); 
string encryptStr = cipher.Encrypt(plainstr); 
writer.write(encryptStr, fileNameDes); 

} 


} 
(5) Program : 客户 端 测试 类 


//Program.cs 
Using System; 


namespace FacadeSample 


{ 
class Program 
{ 
static void Main(string[] args) 
{ 
EncryptFacade ef = new EncryptFacade( ); 
ef.FileEncrypt("src.txt", "des.txt"); 
Console.Read( ); 
} 
} 
} 


编译 并 运行 程序 ， 输 出 结果 如 下 : 


读 取 文件 ， 获 取 明 文 : Hello world! 
数据 加 密 ， 将 明文 转换 为 密 文 : 233364062325 
保存 密 文 ， 写 入 文件 。 


在 本 实例 中 ， 对 文件 src.txt 中 的 数据 进行 加 密 ， 该 文件 内 容 为 “Hello world!”， 加 密 之 后 将 密 文 
保存 到 另 一 个 文件 des.txt 中 ， 程 序 运行 后 保存 在 文件 中 的 密 文 为 “233364062325”。 在 加 密 类 
CipherMachine 中 ， 采 用 求 模 运 算 对 明文 进行 加 密 ， 将 明文 中 的 每 一 个 字符 除 以 一 个 整数 〈 本 
例 中 为 7， 可 以 由 用 户 来 进行 设置 ) 后 取 余 数 作为 密 文 。 
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深入 浅 出 外 观 模式 (三 ) 

1. 抽象 外 观 类 
在 标准 的 外 观 模式 结构 图 中 ， 如 果 需 要 增加 、 删 除 或 更 换 与 外 观 类 交互 的 子 系统 类 ， 必 须 修 
改 外 观 类 或 客户 端的 源 代 码 ， 这 将 违背 开 闭 原则 ， 因 此 可 以 通过 引入 抽象 外 观 类 来 对 系统 进 
行 改进 ， 在 一 定 程度 上 可 以 解决 该 问题 。 在 引入 抽象 外 观 类 之 后 ， 客 户 端 可 以 针对 抽象 外 观 
类 进行 编程 ， 对 于 新 的 业务 需求 ， 不 需要 修改 原 有 外 观 类， 而 对 应 增加 一 个 新 的 具体 外 观 
类 ， 由 新 的 具体 外 观 类 来 关联 新 的 子 系统 对 象 ， 同 时 通过 修改 配置 文件 来 达到 不 修改 任何 源 
代码 并 更 换 外 观 类 的 目的 。 
下 面 通过 一 个 具体 实例 来 学 习 如 何 使 用 抽象 外 观 类 : 


如 果 在 应 用 实例 “文件 加 密 模 块 " 中 需要 更 换 一 个 加 密 类 ， 不 再 使 用 原 有 的 基于 求 模 运算 的 加 密 
类 CipherMachine， 而 改 为 基于 移 位 运算 的 新 加 密 类 NewCipherMachine， 其 代码 如 下 : 


Using System; 


namespace FacadeSample 


{ 
class NewCipherMachine 
{ 
public string Encrypt(string plainText) 
{ 
Console.Write(" 数 据 加 密 ， 将 明文 转换 为 密 文 : "); 
string es = "",; 
int key = 10;// 设 置 密 钥 ， 移 位 数 为 10 
char[] chars = plainText.ToCharArray(); 
foreach(char ch in chars ) 
{ 
int temp = Convert ,ToInt32(ch ) ; 
// 小 写字 母 移 位 
if (ch >= 'a' && ch <= 'z') { 
temp += key % 26; 
if (temp > 122) temp -= 26; 
if (temp < 97) temp += 26; 
} 
// 大 写字 母 移 位 
if (ch >= 'A' && ch <= '7') { 
temp += key % 26; 
if (temp > 90) temp -= 26; 
if (temp < 65) temp += 26; 
} 
es += ((char)temp).ToString(); 
} 
Console,WriteLine(es ) ; 
return es,; 
} 
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} 


如 果 不 增加 新 的 外 观 类 ， 只 能 通过 修改 原 有 和 外观 类 EncryptFacade 的 源 代码 来 实现 加 密 类 的 更 
换 ， 将 原 有 的 对 CipherMachine 类 型 对 象 的 引用 改 为 对 NewCipherMachine 类 型 对 象 的 引用 ， 这 
违背 了 开 闭 原则 ， 因 此 需要 通过 增加 新 的 外 观 类 来 实现 对 子 系统 对 象 引 用 的 改变 。 


如 果 增 加 一 个 新 的 外 观 类 NewEncryptFacade 来 与 FileReader 类 、FileWriter 类 以 及 新 增加 的 
NewCipherMachine 类 进行 交互 ， 虽 然 原 有 系统 类 库 无 须 做 任何 修改 ， 但 是 因为 客户 端 代 码 中 
原来 针对 EncryptFacade 类 进行 编程 ， 现 在 需要 改 为 NewEncryptFacade 类 ， 因 此 需要 修改 客户 端 
源 代码 。 


如 何在 不 修改 客户 端 代 码 的 前 提 下 使 用 新 的 外 观 类 呢 ? 解决 方法 之 一 是 : 引入 一 个 抽象 外 观 
类 ， 客 户 端 针对 抽象 外 观 类 编程 ， 而 在 运行 时 再 确定 具体 外 观 类 ， 引 入 抽象 外 观 类 之 后 的 文 
件 加 密 模 块 结构 图 如 图 5 所 示 : 





- reader : FileReader 
- cipher : CipherMachine 
- Writer : FileWriter 

+ EncryptFacade () 
+ FileEncrypt (string fileNameSrc, : void 
string fileNameDes) 


















FileReader 


+ Read (string fileNameSrc) : string 









FileWriter 


+ Wiite (string encryptText : void 
string fileNameDes) 





CipherMachine 
+ Encrypt (string plainText) : string 


图 5 引入 抽象 外 观 类 之 后 的 文件 加 密 模 块 结构 图 






在 图 5 中 ， 客 户 类 Client 针 对 抽象 外 观 类 AbstractEncryptFacade 进 行 编程 ，AbstractEncryptFacade 
代码 如 下 : 


namespace FacadeSample 


{ 


abstract class AbstractEncryptFacade 
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public abstract void FileEncrypt(string fileNameSrc, string 


} 
新 增 具 体 加 密 外 观 类 NewEncryptFacade 代 码 如 下 : 
[csharp] view plain copy 
namespace FacadeSample 
{ 
class NewEncryptFacade : AbstractEncryptFacade 
{ 
private FileReader reader; 
private NewCipherMachine cipher; 
private Filewriter writer; 


public NewEncryptFacade() 
{ 
reader 
cipher 
writer 


new FileReader(); 
new NewCipherMachine(); 
new Filewriter(); 


} 


public override void FileEncrypt(string fileNameSrc, string 
{ 

string plainStr = reader.Read(fileNameSrc); 

string encryptStr = cipher.Encrypt(plainstr); 

writer .Write(encryptStr, fileNameDes); 


} 
配置 文件 App.config 中 存储 了 具体 外 观 类 的 类 名 ， 代 码 如 下 : 


<?xml1 version="1.0" encoding="utf-8" ?> 
<configuration> 
<appSettings> 
<add key="facade" value="FacadeSample.NewEncryptFacade"/> 
</appSettings> 
</configuration> 


客户 端 测试 代码 修改 如 下 : 


using System; 
Using System.Configuration; 
Using System.Reflection,; 


namespace FacadeSample 


{ 


class Program 


{ 
static void Main(string[] args) 
{ 
AbstractEncryptFacade ef; // 针 对 抽象 外 观 类 编程 
// 读 取 配 置 文件 
string facadeString = ConfigurationManager .AppSettings[™ 
// 反 射 生成 对 象 
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ef = (AbstractEncryptFacade)Assembly.Load("FacadeSample" 
ef.FileEncrypt("src.txt", "des.txt"); 
Console.Read( ); 


} 

编译 并 运行 程序 ， 输 出 结果 如 下 : 

读 取 文件 ， 获 取 明 文 : Hello world! 

数据 加 密 ， 将 明文 转换 为 密 文 : Rovvy gybvn! 
保存 密 文 ， 写 入 文件 。 


原 有 外 观 类 EncryptFacade 也 需 作 为 抽象 外 观 类 AbstractEncryptFacade 类 的 子 类 ， 更 换 具 体外 观 
类 时 只 需 修 改 配置 文件 ， 无 须 修 改 源 代码 ， 符 合 开 闭 原则 。 


1， 外 观 模式 效果 与 适用 场景 
外 观 模 式 是 一 种 使 用 频率 非常 高 的 设计 模式 ， 它 通过 引入 一 个 外 观 角色 来 简化 客户 端 与 子 系 
统 之 间 的 交互 ， 为 复杂 的 子 系统 调用 提供 一 个 统一 的 入 口 ， 使 子 系统 与 客户 端的 耦合 度 降 
低 ， 且 客户 端 调用 非常 方便 。 外 观 模 式 并 不 给 系统 增加 任何 新 功能 ， 它 仅仅 是 简化 调用 接 
口 。 在 几乎 所 有 的 软件 中 都 能 够 找到 外 观 模式 的 应 用 ， 如 绝 大 多 数 B/S 系 统 都 有 一 个 首页 或 者 
导航 页 面 ， 大 部 分 C/S 系 统 都 提供 了 菜单 或 者 工具 栏 ， 在 这 里 ， 首 页 和 导航 页 面 就 是 B/S 系统 
的 外 观 角色 ， 而 菜单 和 工具 栏 就 是 C/S 系 统 的 外 观 角 色 ， 通 过 它们 用 户 可 以 快速 访问 子 系统 ， 
降低 了 系统 的 复杂 程度 。 所 有 涉及 到 与 多 个 业务 对 象 交互 的 场景 都 可 以 考虑 使 用 外 观 模式 进 
行 重 构 。 
5.1 模式 优点 
外 观 模式 的 主要 优点 如 下 : 


(1) 它 对 客户 端 屏 裔 了 子 系统 组 件 ， 减 少 了 客户 端 所 需 处 理 的 对 象 数目 ， 并 使 得 子 系统 使 用 起 
来 更 加 容易 。 通 过 引入 外 观 模式 ， 客 户 端 代码 将 变 得 很 简单 ， 与 之 关联 的 对 象 也 很 少 。 


(2) 它 实现 了 子 系统 与 客户 端 之 间 的 松 耦 合 关系 ， 这 使 得 子 系统 的 变化 不 会 影响 到 调用 它 的 客 
户 端 ， 只 需要 调整 外 观 类 即 可 。 


(3) 一 个 子 系统 的 修改 对 其 他 子 系统 没有 任何 影响 ， 而 且 子 系统 内 部 变化 也 不 会 影响 到 外 观 对 
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5.2 模式 缺点 
外 观 模式 的 主要 缺点 如 下 : 


(1) 不 能 很 好 地 限制 客户 端 直接 使 用 子 系统 类 ， 如 果 对 客户 端 访问 子 系统 类 做 太 多 的 限制 则 减 
少 了 可 变性 和 灵活 性 。 


(2) 如 果 设 计 不 当 ， 增 加 新 的 子 系统 可 能 需要 修改 外 观 类 的 源 代码 ， 违 背 了 开 闭 原则 。 
5.3 模式 适用 场景 

在 以 下 情况 下 可 以 考虑 使 用 外 观 模式 : 

(1) 当 要 为 访问 一 系列 复杂 的 子 系 统 提供 一 个 简单 入 口 时 可 以 使 用 外 观 模式 。 


(2) 客户 端 程序 与 多 个 子 系统 之 间 存 在 很 大 的 依赖 性 。 引 入 外 观 类 可 以 将 子 系统 与 客户 端 解 
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耦 ， 从 而 提高 子 系统 的 独立 性 和 可 移植 性 。 


(3) 在 层次 化 结构 中 ， 可 以 使 用 外 观 模式 定义 系统 中 每 一 层 的 入 口 ， 层 与 层 之 间 不 直接 产生 联 
系 ， 而 通过 外 观 类 建立 联系 ， 降 低层 之 问 的 辜 合 度 。 
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享 元 模式 -Flyweight Pattern 【学习 难度 : 交友 克 友 六， 使 用 频率 : 友 六 六 交 交 】 
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实现 对 输 的 复 用 一 一 和 至 元 模式 (一 ) 
实现 对 输 的 复 用 一 一 和 至 元 模式 (一 ) 


当前 咱们 国家 正在 大 力 倡导 构建 和 谐 社会 ， 其 中 一 个 很 重要 的 组 成 部 分 就 是 建设 资源 节约 型 
社会 ，“ 浪 费 可 耻 ， 节 俭 光荣 ”。 在 软件 系统 中 ， 有 时 候 也 会 存在 资源 浪费 的 情况 ， 例 如 在 计算 
机 内 存 中 存储 了 多 个 完全 相同 或 者 非常 相似 的 对 象 ， 如 果 这 些 对 0 en a 统 运 
行 代价 过 高 ， 内 存 属于 计算 机 的 “稀缺 资源 >*， 不 应 该 用 来 “随便 浪费 ”， 那么 是 否 存 在 一 种 技术 
可 以 用 于 节约 内 存 使 用 空间 ， 实 现 对 这 些 相 同 或 者 相似 对 象 的 共享 访 启 和 呢 ?答案 是 肯定 ， 这 
种 技术 就 是 我 们 本 章 将 要 学 习 的 享 元 模式 。 


14.1 围棋 棋子 的 设计 
Sunny 软 件 公司 欲 开 发 一 个 围棋 软件 ， 其 界面 效果 如 图 14-1 所 示 : 
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图 14-1 围棋 软件 界面 效果 图 


Sunny 软 件 公司 开发 人 员 通 过 对 围棋 软件 进行 分 析 ， 发 现在 围棋 棋盘 中 包含 大 量 的 黑子 和 白 
子 ， 它 们 的 形状 、 大 小 都 一 模 一 样 ， 只 是 出 现 的 位 置 不 同 而 已 。 如 果 将 每 一 个 棋子 都 作为 一 
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个 独立 的 对 象 存储 在 内 存 中 ， 将 导致 该 围棋 软件 在 运行 时 所 需 内 存 空间 较 大 ， 如 何 降低 运行 
代价 、 提 高 系统 性 能 是 Sunny 公 司 开 发 人 员 需 要 解决 的 一 个 问题 。 为 了 解决 这 个 问题 ，Sunny 
公司 开发 人 员 决 定 使 用 享 元 模式 来 设计 该 围棋 软件 的 棋子 对 象 ， 那 么 享 元 模式 是 如 何 实现 节 
约 内 存 进 而 提高 系统 性 能 的 呢 ? 别 着 急 ， 下 面 让 我 们 正式 进入 享 元 模式 的 学 习 。 


14.2 享 元 模式 概述 


当 一 个 软件 系统 在 运行 时 产生 的 对 象 数量 太 多 ， 将 导致 运行 代价 过 高 ， 带 来 系统 性 能 下 降 等 
问题 。 例 如 在 一 个 文本 字符 串 中 存在 很 多 重复 的 字符 ， 如 果 每 一 个 字符 都 用 一 个 单独 的 对 象 
来 表示 ， 将 会 占用 较 多 的 内 存 空 间 ， 那 么 我 们 如 何 去 避 免 系 统 中 出 现 大 量 相同 或 相似 的 对 
象 ， 同 时 又 不 影响 客户 端 程序 通过 面向 对 象 的 方式 对 这 些 对 象 进行 操作 ? 享 元 模式 正 为 解决 
这 一 类 问题 而 诞生 。 享 元 模式 通过 共享 技术 实现 相同 或 相似 对 象 的 重用 ， 在 逻辑 上 每 一 个 出 
现 的 字符 都 有 一 个 对 象 与 之 对 应 ， 然 而 在 物理 上 它们 却 共 享 同一 个 享 元 对 得， 这 个 对 得 可 以 
出 现在 一 个 字符 串 的 不 同 地 方 ， 相 同 的 字符 对 象 都 指向 同一 个 实例 ， 在 享 元 模式 中 ， 存 储 这 
些 共享 实例 对 象 的 地 方 称 为 享 元 池 (Flyweight Pool)。 我 们 可 以 针对 每 一 个 不 同 的 字符 创建 一 个 
享 元 对 象 ， 将 其 放 在 享 元 池 中 ， 需 要 时 再 从 享 元 池 取 出 。 如 图 14-2 所 示 : 


ja 





图 14-2 字符 享 元 对 象 示意 图 


享 元 模式 以 共享 的 方式 高 效 地 支持 大 量 细 粒 度 对 象 的 重用 ， 享 元 对 象 能 做 到 共享 的 关键 是 区 
分 了 内 部 状态 (Intrinsic State) 和 外 部 状态 (Extrinsic State)。 下 面 将 对 享 元 的 内 部 状态 和 外 部 状态 
进行 简单 的 介绍 : 


(1) 内 部 状态 是 存储 在 享 元 对 象 内 部 并 且 不 会 随 环境 改变 而 改变 的 状态 ， 内 部 状态 可 以 共享 。 
如 字符 的 内 容 ， 不 会 随 外 部 环境 的 变化 而 变化 ， 无 论 在 任何 环境 下 字符 “a” 始 终 是 <a” ， 都 不 会 
变 成 “b” 5 


(2) 外 部 状态 是 随 环 境 改变 而 改变 的 、 不 可 以 共享 的 状态 。 享 元 对 象 的 外 部 状态 通常 由 客户 端 
保存， 并 在 享 元 对 象 被 创建 之 后 ， 需 要 使 用 的 时 候 再 传 入 到 享 元 对 象 内 部 。 一 个 外 部 状态 与 
另 一 个 外 部 状态 之 间 是 相互 独立 的 。 如 字符 的 颜色 ， 可 以 在 不 同 的 地 方 有 不 同 的 颜色 ， 例 如 
有 的 “a” 是 红色 的 ， 有 的 “a” 是 绿色 的 ， 字 符 的 大 小 也 是 如 此 ， 有 的 “a” 是 五 号 字 ， 有 的 “a” 是 四 
号 字 。 而 且 字 符 的 颜色 和 大 小 是 两 个 独立 的 外 部 状态 ， 它 们 可 以 独立 变化 ， 相 互 之 间 没 有 影 
响 ， 客 户 端 可 以 在 使 用 时 将 外 部 状态 注入 享 元 对 象 中 。 
正 因为 区 分 了 内 部 状态 和 外 部 状态 ， 我 们 可 以 将 具有 相同 内 部 状态 的 对 象 存储 在 享 元 池 中 ， 
享 元 池 中 的 对 象 是 可 以 实现 共享 的 ， 需 要 的 时 候 就 将 对 象 从 享 元 池 中 取出 ， 实 现 对 象 的 复 
用 。 通 过 向 取出 的 对 象 注入 不 同 的 外 部 状态 ， 可 以 得 到 一 系列 相似 的 对 象 ， 而 这 些 对 象 在 内 
存 中 实际 上 只 存储 一 份 。 

享 元 模式 定义 如 下 : 

享 元 模式 (Flyweight Pattern) : 运用 共享 技术 有 效 地 支持 大 量 细 粒 度 对 象 的 复 用 。 系 统 只 使 
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用 少量 的 对 象 ， 而 这 些 对 象 都 很 相似 ， 状 态 变 化 很 小 ， 可 以 实现 对 象 的 多 次 复 用 。 由 于 
享 元 模式 要 求 能 够 共享 的 对 象 必须 是 细 粒 度 对 象 ， 因 此 它 又 称 为 轻 量 级 模式 ， 它 是 一 种 
对 象 结构 型 模式 。 
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享 元 模式 结构 较为 复杂 ， 一 般 结 合 工厂 模式 一 起 使 用 ， 在 它 的 结构 图 中 包含 了 一 个 享 元 工厂 
类 ， 其 结构 图 如 图 14-3 所 示 : 


FlyweightFactory 这 Flyweight 
- flyweights : HashMap fyweights | 
RE 











+ getFlyweight (String key) : Flyweight 人 


四 
' 


if(flyweights.containsKey(key)) { 
return (Flyweight flyweights.get(key); : | 
.本 { ConcreteFlyweight UnsharedConcreteFlyweight 
Flyweight fw=new ConcreteFlyweight(): - intrinsicState : - allState : 


me pe i + operation ( extrinsicState) | |+ operation ( extrinsicState) 


} 








图 14-3 享 元 模式 结构 图 
在 享 元 模式 结构 图 中 包含 如 下 几 个 角色 : 


。 Flyweight (抽象 享 元 类 ) : 通常 是 一 个 接口 或 抽象 类 ， 在 抽象 享 元 类 中 声明 了 具体 享 元 类 公 
共 的 方法 ， 这 些 方法 可 以 向 外 界 提供 享 元 对 象 的 内 部 数据 (内 部 状态 ) ， 同 时 也 可 以 通过 这 
些 方法 来 设置 外 部 数据 (外 部 状态 ) 。 


e@ ConcreteFlyweight ( 具体 享 元 类 ) : 它 实现 了 抽象 享 元 类 ， 其 实例 称 为 享 元 对 象 ; 在 具体 享 
元 类 中 为 内 部 状态 提供 了 存储 空间 。 通 常 我 们 可 以 结合 单 例 模 式 来 设计 具体 享 元 类 ， 为 每 一 
个 具体 享 元 类 提供 唯一 的 享 元 对 象 。 


e@ UnsharedConcreteFlyweight 〈 非 共享 具体 享 元 类 ) : 并 不 是 所 有 的 抽象 享 元 类 的 子 类 都 需要 
被 共享 ， 不 能 被 共享 的 子 类 可 设计 为 非 共 享 具体 享 元 类 ; 当 需 要 一 个 非 共享 具体 享 元 类 的 对 
象 时 可 以 直接 通过 实例 化 创建 。 


@ FlyweightFactory ( 享 元 工厂 类 ) : 享 元 工厂 类 用 于 创建 并 管理 享 元 对 象 ， 它 针对 抽象 享 元 
类 编程 ， 将 各 种 类 型 的 具体 享 元 对 象 存储 在 一 个 享 元 池 中 ， 享 元 池 一 般 设 计 为 一 个 存储 “ 键 值 
对 ”的 集合 (也 可 以 是 其 他 类 型 的 集合 ) ， 可 以 结合 工厂 模式 进行 设计 ; 当 用 户 请 求 一 个 具体 
享 元 对 象 时 ， 享 元 工厂 提供 一 个 存储 在 享 元 池 中 已 创建 的 实例 或 者 创建 一 个 新 的 实例 (如 果 
不 存在 的 话 ) ， 返 回 新 创建 的 实例 并 将 其 存储 在 享 元 池 中 。 


在 享 元 模式 中 引入 了 享 元 工厂 类 ， 享 元 工厂 类 的 作用 在 于 提供 一 个 用 于 存储 享 元 对 象 的 享 元 
池 ， 当 用 户 需要 对 象 时 ， 首 先 从 享 元 池 中 获取 ， 如 果 享 元 池 中 不 存在 ， 则 创建 一 个 新 的 享 元 
对 象 返回 给 用 户 ， 并 在 享 元 池 中 保存 该 新 增 对 象 。 典 型 的 享 元 工厂 类 的 代码 如 下 : 


class FlyweightFactory { 


// 定 义 一 个 HashMap 用 于 存储 享 元 对 象 ， 实 现 享 元 池 
private HashMap flyweights = newHashMap(); 
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public Flyweight getFlyweight(String key)t{ 
// 如 果 对 象 存在 ， 则 直接 从 享 元 池 获 取 
if(flyweights.containskey(key))t 
return(Flyweight)flyweights.get(key); 


} 
// 如 果 对 象 不 存在 ， 先 创建 一 个 新 的 对 象 添 加 到 享 元 池 中 ， 然 后 返回 
else { 
Flyweight fw = newConcreteFlyweight(); 
f]lyweights.put(keyfw)， 
return fw; 


} 

享 元 类 的 设计 是 享 元 模式 的 要 点 之 一 ， 在 享 元 类 中 要 将 内 部 状态 和 外 部 状态 分 开 处 理 ， 通 常 
将 内 部 状态 作为 享 元 类 的 成 员 变 量 ， 而 外 部 状态 通过 注入 的 方式 添加 到 享 元 类 中 。 典 型 的 享 
元 类 代码 如 下 所 示 : 


class Flyweight { 
// 内 部 状态 intrinsicState 作 为 成 员 变量 ， 同 一 个 享 元 对 象 其 内 部 状态 是 一 致 的 
private String intrinsicState， 


public Flyweight(String intrinsicState) { 
this.intrinsicState=intrinsicState; 


} 


// 外 部 状态 extrinsicSstate 在 使 用 时 由 外 部 设置 ， 不 保存 在 享 元 对 答 中 ， 即 使 
public void operation(String extrinsicState) { 


} 
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为 了 节约 存储 空间 ， 提 高 系统 性 能 ，Sunny 公 司 开 发 人 员 使 用 享 元 模式 来 设计 围棋 软件 中 的 棋 
子 ， 其 基本 结构 如 图 14-4 所 示 : 








lgoChessmanFactory 





lgoChessman 






- instance : lgoChessmanFacto 

- ht pashlie {abstract} 
-lgoChessmanFactory() | 
+ getinstance () : lgoChessmanFactory + getColor () : String 





+ getlgoChessman (String color) : lgoChessman 和 csplay Oe :void 








BlacklgoChessman 


WhitelgoChessman 


+ getColor () : String 


+ getColor () : String | 





图 14-4 围棋 棋子 结构 图 


在 图 14-4 中 ，IgoChessman 充 当 抽象 享 元 类 ，BlackIgoChessman 和 WhitelgoChessman 充 当 具 体 享 
元 类 ，IgoChessmanFactory 充 当 享 元 工厂 类 。 完 整 代码 如 下 所 示 : 


import java.util.*; 


// 围 棋 棋 子 类 : 抽象 享 元 类 
abstract class IgoChessman { 
public abstract String getColor(); 


public void display() { 
System.out.println(" 棋 子 颜色 :" + this.getcolor()); 
} 


} 


// 黑 色 棋 子 类 : 具体 享 元 类 
class BlackIgoChessman extends IgoChessman { 
public String getColor() { 
return "黑色 "， 
} 
} 


// 和 白色 棋子 类 : 具体 享 元 类 
class WhiteIgoChessman extends IgoChessman { 
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} 


public String getColor() { 


} 


return "白色"， 


// 围 棋 棋 子 工厂 类 : 享 元 工厂 类 ， 使 用 单 例 模 式 进行 设计 

class IgoChessmanFactory { 

private static IgoChessmanFactory instance = new IgoChessmanFact 
private static Hashtable ht; // 使 用 Hashtable 来 存储 享 元 对 象 ， 充 当 享 元 兴 


} 


private IgoChessmanFactory() { 


} 


ht = new Hashtable(); 
IgoChessman black,white; 

black = new BlackIgoChessman( ); 
ht.put("b",black); 

white = new WhiteIlgoChessman(); 
ht.put("w",white); 


// 返 回 享 元 工厂 类 的 唯一 实例 
public static IgoChessmanFactory getInstance() { 


} 


return instance; 


// 通 过 key 来 获取 存储 在 Hashtab1le 中 的 享 元 对 象 
public static IgoChessman getIgoChessman(String color) { 


} 


return (IgoChessman)ht.get(color); 


编写 如 下 客户 端 测 试 代 码 : 


class Client { 
public static void main(String args[]) { 
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IgoChessman blacki1,black2,black3,whitel1,white2; 
IgoChessmanFactory factory; 


// 获 取 享 元 工厂 对 象 
factory = IgoChessmanFactory ,getInstance( ) ; 


// 通 过 享 元 工厂 获取 三 颗 黑 子 


black1 = factory.getIigoChessman("b"); 
black2 = factory.getIigoChessman("b"); 
black3 = factory.getIigoChessman("b"); 


System.out.println(" 判 断 两 颗 黑 子 是 否 相 同 :" + (black1==black2)); 


// 通 过 享 元 工厂 获取 两 颗 白 子 

white1 = factory.getIgoChessman("w"); 

white2 = factory.getIgoChessman("w"); 
System.out.println(" 判 断 两 颗 白 子 是 否 相 同 : " + (white1==white2)); 


// 显 示 棋 子 
black1.display()， 
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black2.display() 
black3.display() 
white1.display(); 
white2.display(); 


了 
了 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


判断 两 蜂 黑 子 是 否 相同 : true 
判断 两 蜂 白 子 是 否 相同 : true 
棋子 颜色 : 黑色 
棋子 颜色 : 黑色 
棋子 颜色 : 黑色 
棋子 颜色 : 白色 
棋子 颜色 : 白色 


从 输出 结果 可 以 看 出 ， 虽 然 我 们 获取 了 三 个 黑子 对 象 和 两 个 白 子 对 象 ， 但 是 它们 的 内 存 地 址 


相同 ， 也 就 是 说 ， 它 们 实际 上 是 同一 个 对 象 。 在 实现 享 元 工厂 类 时 我 们 使 用 了 单 例 模式 和 简 
单 工厂 模式 ， 确 保 了 享 元 工厂 对 象 的 唯一 性 ， 并 提供 工厂 方法 来 向 客户 端 返 回 享 元 对 象 。 
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14.5 带 外 部 状态 的 解决 方案 


Sunny 软 件 公司 开发 人 员 通 过 对 围棋 棋子 进行 进一步 分 析 ， 发 现 虽然 黑色 棋子 和 白色 棋子 可 以 
共享 ， 但 是 它们 将 显示 在 棋盘 的 不 同位 置 ， 如 何 让 相同 的 黑子 或 者 白 子 能 够 多 次 重复 显示 上 且 
位 于 一 个 棋盘 的 不 同 地 方 ? 解决 方法 就 是 将 棋子 的 位 置 定 义 为 棋子 的 一 个 外 部 状态 ， 在 需要 
时 再 进行 设置 。 因 此 ， 我 们 在 图 14-4 中 增加 了 一 个 新 的 类 Coordinates (坐标 类 ) ， 用 于 存储 每 
一 个 棋子 的 位 置 ， 修 改 之 后 的 结构 图 如 图 14-5 所 示 : 


-Xx :int 
-Yy :int 


+ Coordinates (int x, int y) 





















lgoCh Fact 
= A lIgoChessman 
- instance :lgoChessmanFactory {abstract} 
- ht - Hashtable . 
- lgoChessmanFactory () 一 
+ getlnstance () :lgoChessmanFactory + getColor () : String 










+ getlgoChessman (String color) : lgoChessman + display ne coord) : void 


















BlacklgoChessman 
+ getColor () : String 


WhitelgoChessman 
+ getColor () : String 


图 14-5 引入 外 部 状态 之 后 的 围棋 棋子 结构 图 


在 图 14-5 中 ， 除 了 增加 一 个 坐标 类 Coordinates 以 外 ， 抽 象 享 元 类 IgoChessman 中 的 display() 方 法 
也 将 对 应 增加 一 个 Coordinates 类 型 的 参数 ， 用 于 在 显示 棋子 时 指定 其 坐标 ，Coordinates 类 和 修 
改 之 后 的 IgoChessman 类 的 代码 如 下 所 示 : 


// 坐 标 类 : 外 部 状态 类 

class Coordinates { 
private int x; 
private int y; 


public Coordinates(int x,int y) { 


this.x = x; 
this.y = y; 
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public int getX() { 
return this.x; 


} 


public void SetX(int x) { 
this.x = x; 
} 


public int getY() { 
return this.y; 


} 

public void setY(int y) { 
this.y = y; 

} 


} 


// 围 棋 棋 子 类 : 抽象 享 元 类 
abstract class IgoChessman { 
public abstract String getColor(); 


public void display(Coordinates coord)t{ 
System.out.println(" 棋 子 颜 色 :" + this.getColor() + "， 棋 子 位 置 
} 
} 


客户 端 测试 代码 修改 如 下 : 


class Client { 
public static void main(String args[]) { 
IgoChessman blacki1,black2,black3,whitel1,white2; 
IgoChessmanFactory factory; 


// 获 取 享 元 工厂 对 象 
factory = IgoChessmanFactory ,getInstance( ); 


// 通 过 享 元 工厂 获取 三 颗 黑 子 

black1 = factory.getIgoCchessman("b") 
black2 factory.getIigoCchessman("b") 
black3 factory.getIigoCchessman("b") 
System.out.println(" 判 断 两 颗 黑 子 是 否 相 同 :" + (black1==black2)); 


// 通 过 享 元 工厂 获取 两 颗 白 子 

white1 = factory.getIgoChessman("w"); 

white2 = factory.getIgoChessman("w"); 
System.out.println(" 判 断 两 颗 白 子 是 否 相 同 : " + (white1==white2)); 


// 显 示 棋 子 ， 同 时 设置 棋子 的 坐标 位 置 

blacki.display(new Coordinates(1,2)); 
black2.display(new Coordinates(3,4)); 
black3.display(new Coordinates(1,3)); 
whitei1.display(new Coordinates(2,5)); 
white2.display(new Coordinates(2,4)); 
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} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


判断 两 颗 黑 子 是 否 相 同 : true 

判断 两 颗 白 子 是 否 相 同 : true 

棋子 颜色 : 黑色 ， 棋 子 位 置 : 1 ，2 
棋子 颜色 : 黑色 ， 棋 子 位 置 : 3，4 
棋子 颜色 : 黑色 ， 棋 子 位 置 : 1，3 
棋子 颜色 : 白色 ， 棋 子 位 置 : 2，5 
棋子 颜色 : 和 白色， 棋子 位 置 : 2，4 


从 输出 结果 可 以 看 到 ， 在 每 次 调用 display() 方 法 时 ， 都 设置 了 不 同 的 外 部 状态 坐标 值 ， 因 
此 相同 的 棋子 对 象 虽然 具有 相同 的 颜色 ， 但 是 它们 的 坐标 值 不 同 ， 将 显示 在 棋盘 的 不 同位 
置 。 
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14.5 单纯 享 元 模式 和 复合 享 元 模式 

标准 的 享 元 模式 结构 图 中 既 包 含 可 以 共享 的 具体 享 元 类 ， 也 和 包含 不 可 以 共享 的 非 共 享 具体 享 
元 类 。 但 是 在 实际 使 用 过 程 中 ， 我 们 有 时 候 会 用 到 两 种 特殊 的 享 元 模式 : 单纯 享 元 模式 和 复 
合 享 元 模式 ， 下 面 将 对 这 两 种 特殊 的 享 元 模式 进行 简单 的 介绍 : 

1. 单 纯 享 元 模式 


在 单纯 享 元 模式 中 > 所 有 的 具体 享 元 类 都 是 可 以 共享 的 ? 不 存在 非 共 享 具 体 享 元 类 单纯 享 
元 模式 的 结构 如 图 14-6 所 示 : 








FlyweightFactory 
- flyweights : HashMap 


+ getFlyweight (String key) : Flyweight 

















性 Flyweight 


flyweights 
+ operation ( extrinsicState) 












ConcreteFlyweight 
- intrinsicState : 








+ operation ( extrinsicState) 


图 14-6 单纯 享 元 模式 结构 图 
2. 复 合 享 元 模式 
将 一 些 单纯 享 元 对 象 使 用 组 合 模式 加 以 组 合 ， 还 可 以 形成 复合 享 元 对 象 ， 这 样 的 复合 享 元 对 


象 本 身 不 能 共享 ， 但 是 它们 可 以 分 解 成 单纯 享 元 对 象 ， 而 后 者 则 可 以 共享 。 复 合 享 元 模式 的 
结构 如 图 14-7 所 示 : 






FlyweightFactory 人 Flyweight 


- flyweights : HashMap 
区 > 
+ getFlyweight (String key) : Flyweight + operation ( extrinsicState) 
AN 








ConcreteFlyweight : | CompositeConcreteFlyweight 





- intrinsicState : |- fiyweights : 


+ operation ( extrinsicState) + operation ( extrinsicState) 


+ add (Flyweight flyweight) 
+ remove (Flyweight flyweight) 
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图 14-7 复合 享 元 模式 结构 图 

通过 复合 享 元 模式 ， 可 以 确保 复合 享 元 类 CompositeConcreteFlyweight 中 所 包含 的 每 个 单纯 享 
元 类 ConcreteFlyweight 都 具有 相同 的 外 部 状态 ， 而 这 些 单 纯 享 元 的 内 部 状态 往往 可 以 不 同 。 如 
果 硕 望 为 多 个 内 部 状态 不 同 的 享 元 对 象 设 置 相同 的 外 部 状态 ， 可 以 考虑 使 用 复合 享 元 模式 。 
14.6 关于 享 元 模式 的 几 点 补充 

1. 与 其 他 模式 的 联 用 

享 元 模式 通常 需要 和 其 他 模式 一 起 联 用 ， 几 种 常见 的 联 用 方式 如 下 : 


(TD 在 享 元 模式 的 享 元 工厂 类 中 通常 提供 一 个 静态 的 工厂 方法 用 于 返回 享 元 对 象 ， 使 用 简单 工 
厂 模式 来 生成 享 元 对 象 。 


(2) 在 一 个 系统 中 ， 通 常 只 有 唯一 一 个 享 元 工厂 ， 因 此 可 以 使 用 单 例 模式 进行 享 元 工厂 类 的 设 
计 。 


(3) 享 元 模式 可 以 结合 组 合 模式 形成 复合 享 元 模式 ， 统 一 对 多 个 享 元 对 象 设置 外 部 状态 。 
2. 享 元 模式 与 String 类 
JDK 类 库 中 的 String 类 使 用 了 享 元 模式 ， 我 们 通过 如 下 代码 来 加 以 说 明 : 


class Demo { 
public static void main(String args[]) { 


String str1i = "abcd"; 

String str2 = "abcd"; 

String str3 = "ab" + "cd"，; 

String str4 = "ab"; 

str4 += "cd"; 
System.out.println(str1i == str2); 
System.out.printlin(str1i == str3); 
System.out.println(str1i == str4); 
Str2 += "e"; 
System.out.println(str1i == str2); 


} 


在 Java 语 言 中 ， 如 果 每 次 执行 类 似 String str1="abcd" 的 操作 时 都 创建 一 个 新 的 字符 串 对 象 将 导 
致 内存 开 销 很 大 ， 因 此 如 果 第 一 次 创建 了 内 容 为 "abcd" 的 字符 串 对 象 str1， 下 一 次 再 创建 内 容 
相同 的 字符 串 对 象 str2 时 会 将 它 的 引用 指向 "abcd"， 不 会 重新 分 配 内 存 空 间 ， 从 而 实现 

了 "abcd" 在 内 存 中 的 共享 。 上述 代 码 输出 结果 如 下 : 


true 
true 
false 
false 


可 以 看 出 ， 前 两 个 输出 语 匈 均 为 rue， 说 明 strl、str2、str3 在 内 存 中 引用 了 相同 的 对 象 ; 如 果 
有 一 个 字符 串 str4， 其 初 值 为 "ab"， 再 对 它 进行 操作 str4 += "cd"， 此 时 虽然 str4 的 内 容 与 str1 相 
同 ， 但 是 由 于 str4 的 初始 值 不 同 ， 在 创建 str4 时 重新 分 配 了 内 存 ， 所 以 第 三 个 输出 语 多 结果 为 
false ; 最 后 一 个 输出 语句 结果 也 为 false， 说 明 当 对 str 2 进行 修改 时 将 创建 一 个 新 的 对 象 ， 修 改 
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工作 在 新 对 象 上 完成 ， 而 原来 引用 的 对 象 并 没有 发 生 任何 改变 ，str1 仍 然 引 用 原 有 对 象 ， 而 
str2 引 用 新 对 象 ，strl 与 str2 引 用 了 两 个 完全 不 同 的 对 象 。 


扩展 
关于 Java String 类 这 种 在 修改 享 元 对 象 时 ， 先 将 原 有 对 象 复制 一 份 ， 然 后 在 新 对 象 上 再 实 
施 修改 操作 的 机 制 称 为 “Copy On Write”， 大 家 可 以 自行 查询 相关 资料 来 进一步 了 解 和 学 
习 “Copy On Write” 机 制 ， 在 此 不 作 详细 说 明 。 
14.7 享 元 模式 总 结 
当 系 统 中 存在 大 量 相同 或 者 相似 的 对 象 时 ， 享 元 模式 是 一 种 较 好 的 解决 方案 ， 它 通过 共享 技 
人 同 或 相似 的 细 粒 度 对 象 的 复 用 ， 从 而 节约 了 内 存 空 间 ， 提 高 了 系统 性 能 。 相 比 其 他 
结构 型 设计 模式 ， 享 元 模式 的 使 用 频率 并 不 算 太 高 ， 但 是 作为 一 种 以 “节约 内 存 ， 提 高 性 能 ”为 
出 发 ， 点 的 设计 模式 ， 它 在 软件 开发 中 还 是 得 到 了 一 定 程度 的 应 用 。 
1. 主 要 优点 
享 元 模式 的 主要 优点 如 下 : 


(1) 可 以 极 大 减少 内 存 中 对 象 的 数量 ， 使 得 相同 或 相似 对 象 在 内 存 中 只 保存 一 份 ， 从 而 可 以 节 
约 系统 资源 ， 提 高 系统 性 能 。 


(2) 享 元 模式 的 外 部 状态 相对 独立 ， 而 且 不 会 影响 其 内 部 状态 ， 从 而 使 得 享 元 对 象 可 以 在 不 同 
的 环境 中 被 共享 。 


2. 主 要 缺点 
享 元 模式 的 主要 缺点 如 下 : 


(1) 享 元 模式 使 得 系统 变 得 复杂 ， 需 要 分 离 出 内 部 状态 和 外 部 状态 ， 这 使 得 程序 的 逻辑 复杂 
化 。 


(2) 为 了 使 对 象 可 以 共享 ， 享 元 模式 需要 将 享 元 对 象 的 部 分 状态 外 部 化 ， 而 读 取 外 部 状态 将 全 
得 运行 时 间 变 长 。 


3. 适 用 场景 

在 以 下 情况 下 可 以 考虑 使 用 享 元 模式 : 

(1) 一 个 系统 有 大 量 相 同 或 者 相似 的 对 象 ， 造 成 内 存 的 大 量 耗 党 。 

(2) 对 象 的 大 部 分 状态 都 可 以 外 部 化 ， 可 以 将 这 些 外 部 状态 传 入 对 象 中 。 


(3) 在 使 用 享 元 模式 时 需要 维护 一 个 存储 享 元 对 象 的 享 元 池 ， 而 这 需要 耗费 一 定 的 系统 资源 ， 
因此 ， 应 当 在 需要 多 次 重复 使 用 享 元 对 象 时 才 值 得 使 用 享 元 模式 。 


练习 
Sunny 软 件 公司 欲 开 发 一 个 乡 功 人 文档 编辑 器 ， 在 文本 文档 中 可 以 插入 图 片 、 动 画 、 视 频 
等 多 媒体 资料 ， 为 了 节约 系统 资源 ， 相同 的 图 片 、 动画 和 视频 在 同一 个 文档 中 只 需 保 存 


一 份 ， 但 是 可 以 多 次 重复 出 现 ， 而 且 它 们 每 次 出 现时 位 置 和 大 小 均 可 不 同 。 试 使 用 享 元 
模式 设计 该 文档 编辑 器 。 
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代理 模式 -Proxy Pattern 【学 习 难 度 : 克 交 克 六 六 ， 使 用 频率 : 交友 六 交 交 】 


231 


设计 模式 之 代理 模式 (一 ) 


设计 模式 之 代理 模式 (一 ) 
设计 模式 之 代理 模式 (一 ) 


代理 模式 是 常用 的 结构 型 设计 模式 之 一 ， 当 无 法 直接 访问 某 个 对 象 或 访问 某 个 对 象 存在 困难 
时 可 以 通过 一 个 代理 对 象 来 间接 访问 ， 为 了 保证 客户 端 使 用 的 透明 性 ， 所 访问 的 由 实 对 象 与 
代理 对 象 需要 实现 相同 的 接口 。 根 据 代理 模式 的 使 用 目的 不 同 ， 代 理 模式 又 可 以 分 为 多 种 类 
型 ， 例 如 保护 代理 、 远 程 代 理 、 虚 拟 代 理 、 缓 冲 代理 等 ， 它 们 应 用 于 不 同 的 场合 ， 满 足 用 户 
的 不 同 需求 。 


15.1 代理 模式 概述 


近年 来 ， 代 购 已 逐步 成 为 电子 商务 的 一 个 重要 分 支 。 何 谓 代购 ， 简 单 来 说 就 是 找 人 帮忙 购买 
所 需要 的 商品 ， 当 然 你 可 能 需要 向 实施 代购 的 人 支付 一 定 的 费用 。 代 购 通常 分 为 两 种 类 型 : 

一 种 是 因为 在 当地 买 不 到 某 件 商品 ， 又 或 者 是 因为 当地 这 件 商品 的 价格 比 其 他 地 区 的 贵 ， 因 

此 托 人 在 其 他 地 区 甚至 国外 购买 该 商品 ， 然 后 通过 快递 发 货 或 者 直接 携带 回来 ; 还 有 一 种 代 
购 ， 由 于 消费 者 对 想 要 购买 的 商品 相关 信息 的 缺乏 ， 自 己 无 法 确定 其 实际 价值 而 又 不 想 被 商 
家 宰 ， 只 好 委托 中 介 机 构 帮 其 讲价 或 为 其 代 买 。 代 购 网 站 为 此 应 运 而 生 ， 它 为 消费 者 提供 在 
线 的 代购 服务 ， ee ， 可 以 登录 代购 网 站 圭 写 代购 单 并 付款 ， 
代购 网 站 会 帮助 进行 购买 然后 通过 快递 公司 将 商品 发 送 给 消费 者 。 商 品 代购 过 程 如 图 15-1 所 


购买 商品 -内 商品 [全 -人 而 商品 代购 商品 


顾客 代购 网 站 商品 





图 15-1 商品 代购 示意 图 


在 软件 开发 中 ， 也 有 一 种 设计 模式 可 以 提供 与 代购 网 站 类 似 的 功能 。 由 于 某 些 原因 ， 客 户 端 
不 想 或 不 能 直接 访问 一 个 对 象 ， 此 时 可 以 通过 一 个 称 之 为 “代理 ”的 第 三 者 来 实现 间接 访问 ， 该 
方案 对 应 的 设计 模式 被 称 为 代理 模式 。 


代理 模式 是 一 种 应 用 很 广泛 的 结构 型 设计 模式 ， 而 且 变 化 形式 非常 多 ， 常 见 的 代理 形式 包括 
远程 代理 、 保 护 代理 、 虚 拟 代理 、 缓 冲 人 代理、 智能 引用 代理 等 ， 后 面 将 学 习 这 些 不 同 的 代理 
形式 。 

代理 模式 定义 如 下 : 

代理 模式 : 给 某 一 个 对 象 提供 一 个 代理 或 占 位 符 ， 并 由 代理 对 象 来 控制 对 原 对 象 的 访问 。 


Proxy Pattern: Provide a surrogate or placeholder for another object to control access to it. 


代理 模式 是 一 种 对 象 结 构 型 模式 。 在 代理 模式 中 引入 了 一 个 新 的 代理 对 象 ， 代 理 对 象 在 客户 
端 对 象 和 目标 对 象 之 间 起 到 中 介 的 作用 ， 它 去 掉 客 户 不 能 看 到 的 内 容 和 服务 或 者 增添 客户 需 
要 的 额外 的 新 服务 


15.2 代理 模式 结构 与 实现 
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15.2.1 模式 结构 


代理 模式 的 结构 比较 简单 ， 其 核心 是 代理 类 ， 为 了 让 客户 端 能 够 一 致 性 地 对 待 真 实 对 象 和 代 
理 对 象 ， 在 代理 模式 中 引入 了 抽象 层 ， 代 理 模式 结构 如 图 15-2 所 示 : 


i 
= 









+ Request () 
图 15-2 代理 模式 结构 图 


A 
realSubject 
由 图 15-2 可 知 ， 代 理 模式 包含 如 下 三 个 角色 : 


(1) Subject (抽象 主题 角色 ) : 它 声明 了 站 实 主题 和 代理 主题 的 共同 接口 ， 这 样 一 来 在 任何 使 
用 监 实 主题 的 地 方 都 可 以 使 用 代理 主题 ， 客 户 端 通常 需要 针对 抽象 主题 角色 进行 编程 。 
















- realSubject : RealSubject 


+ PreRequest () 
+ Request () 
d+ PostRequest () 







Es 





PreRequest(); 
realSubject.Request(), 
PostRequest(); 





(2) Proxy (代理 主题 角色 ) : 它 包 含 了 对 监 实 主题 的 引用 ， 从 而 可 以 在 任何 时 候 操 作 监 实 主题 
对 象 ; 在 代理 主题 角色 中 提供 一 个 与 丫 实 主题 角色 相同 的 接口 ， 以 便 在 任何 时 候 都 可 以 蔡 代 
监 实 主 题 ; 代理 主题 角色 还 可 以 控制 对 申 实 主题 的 使 用 ， 负 责 在 需要 的 时 候 创建 和 删除 上 羡 实 
主题 对 和 象 ， 并 对 丨 实 主题 对 象 的 使 用 加 以 约束 。 通 常 ， 在 代理 主题 角色 中 ， 客 户 端 在 调用 所 
引用 的 监 实 主题 操作 之 前 或 之 后 还 需要 执行 其 他 操作 ， 而 不 仅仅 是 单纯 调用 站 实 主题 对 象 中 
的 操作 。 

(3) RealSubject ( 申 实 主题 角色 ) : 它 定 义 了 代理 角色 所 代表 的 丨 实 对 银 ， 在 监 实 主 题 角 色 中 
实现 耻 实 的 业务 操作 ， 容 户 端 可 以 通过 代理 主题 角色 问 接 调用 昌 实 主题 角色 中 定义 的 操 
作 。 

15.2.2 模式 实现 


代理 模式 的 结构 图 比较 简单 ， 但 是 在 旧 实 的 使 用 和 实现 过 程 中 要 复杂 很 多 ， 特 别 是 代理 类 的 
设计 和 实现 。 


抽象 主题 类 声明 了 丨 实 主题 类 和 代理 类 的 公共 方法 ， 它 可 以 是 接口 、 抽 答 类 或 具体 类 ， 客 户 
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端 针 对 抽象 主题 类 编程 ， 一 致 性 地 对 待 丨 实 主题 和 代理 主题 ， 典 型 的 抽象 主题 类 代码 如 下 : 
abstract class Subject 


public abstract void Request(); 


} 
真实 主题 类 继承 了 抽象 主题 类 ， 提 供 了 业务 方法 的 具体 实现 ， 其 典型 代码 如 下 : 
class RealSubject : Subject 
public override void Request() 
// 业 务 方法 具体 实现 代码 
} 


代理 类 也 是 抽象 主题 类 的 子 类 ， 它 维持 一 个 对 丨 实 主 题 对 象 的 引用 ， 调 用 在 丨 实 主 题 中 实现 
的 业务 方法 ， 在 调用 时 可 以 在 原 有 业务 方法 的 基础 上 附加 一 些 新 的 方法 来 对 功能 进行 扩充 或 
约束 ， 最 简单 的 代理 类 实现 代码 如 下 : 


class Proxy : Subject 


{ 
private RealSubject realSubject = new RealSubject(); // 维 持 一 个 对 点 
public void PreRequest() 
{ 
} 
public override void Request() 
{ 
PreRequest(); 
realSubject.Request(); // 调 用 申 实 主题 对 象 的 方法 
PostRequest(); 
} 
public void PostRequest() 
{ 
} 
} 


在 实际 开发 过 程 中 ， 代 理 类 的 实现 比 上 述 代码 要 复杂 很 多 ， 代 理 模式 根据 其 目的 和 实现 方式 
不 同 可 分 为 很 多 种 类 ， 其 中 常用 的 几 种 代理 模式 简要 说 明 如 下 : 

(1) 远程 代理 (Remote Proxy) : 为 一 个 位 于 不 同 的 地 址 空间 的 对 象 提 供 一 个 本 地 的 代理 对 象 ， 这 
个 不 同 的 地 址 空间 可 以 是 在 同一 台 主 机 中 ， 也 可 是 在 另 一 台 主 机 中 ， 远 程 代理 又 称 为 大 使 
(Ambassador)。 


(2) 虚拟 代理 (Virtual Proxy) : 如 果 需 要 创建 一 个 资源 消耗 较 大 的 对 象 ， 先 创建 一 个 消耗 相对 较 
小 的 对 象 来 表示 ， 昌 实 对 象 只 在 需要 时 才 会 被 监 正 创建 。 


(3) 保护 代理 (Protect Proxy) : 控制 对 一 个 对 象 的 访问 ， 可 以 给 不 同 的 用 户 提 供 不 同 级 别 的 使 用 


234 


设计 模式 之 代理 模式 (一 ) 


权限 。 


(4) 缓冲 代理 (Cache Proxy) : 为 某 一 个 目标 操作 的 结果 提供 临时 的 存储 空间 ， 以 便 多 个 客户 端 
可 以 共享 这 些 结果 。 


(5) 智能 引用 代理 (Smart Reference Proxy) : 当 一 个 对 象 被 引用 时 ， 提 供 一 些 额 外 的 操作 ， 例 如 
将 对 象 被 调用 的 次 数 记 录 下 来 等 。 


在 这 些 常用 的 代理 模式 中 ， 有 些 代理 类 的 设计 非常 复杂 ， 例 如 远程 代理 类 ， 它 封装 了 底层 网 
络 通信 和 对 远程 对 象 的 调用 ， 其 实现 较为 复杂 。 
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设计 模式 之 代理 模式 (二 ) 
设计 模式 之 代理 模式 (二 ) 
15.3 代理 模式 应 用 实例 

下 面 通过 一 个 应 用 实例 来 进一步 学 习 和 理解 代理 模式 。 


1. 实例 说 明 


某 软 件 公 司 承接 了 某 信息 咨询 公司 的 收费 商务 信息 查询 系统 的 开发 任务 ， 该 系统 的 基本 需求 
如 下 : 


(1) 在 进行 商务 信息 查询 之 前 用 户 需 要 通过 身份 验证 ， 只 有 合法 用 户 才能 够 使 用 该 查询 系统 ; 


(2) 在 进行 商务 信息 查询 时 系统 需要 记录 查询 日 志 ， 以 便 根 据 查 询 次 数 收取 查询 费用 。 


BA 


该 软件 公司 开发 人 员 已 完成 了 商务 信息 查询 模块 的 开发 任务 ， 现 希望 能 够 以 一 种 松 耦 合 的 方 
式 向 原 有 系统 增加 身份 验证 和 日 志 记录 功能 ， 客 户 端 代码 可 以 无 区 别 地 对 待 原始 的 商务 信息 
查询 模块 和 增加 新 功能 之 后 的 商务 信息 查询 模块 ， 而 且 可 能 在 将 来 还 要 在 该 信息 查询 模块 中 
增加 一 些 新 的 功能 。 
试 使 用 代理 模式 设计 并 实现 该 收费 商务 信息 查询 系统 。 

1.， 实例 分 析 及 类 图 
通过 分 析 ， 可 以 采用 一 种 间接 访问 的 方式 来 实现 该 商务 信息 查询 系统 的 设计 ， 在 客户 端 对 象 


通 
无 须 直 接 对 原 有 的 商务 信息 查询 对 象 进行 修改 ， 如 图 15-3 所 示 : 










AU 一 二 访 问 > zp 

客户 端 对 象 一 代理 对 象 

喘 份 验证 商务 信息 查询 
商务 信息 查询 






日 志 记 录 


图 15-3 商务 信息 查询 系统 设计 方案 示意 图 
在 图 15-3 中 ， 客 户 端 对 象 通过 代理 对 象 间接 访问 具有 商务 信息 查询 功能 的 站 实 对 象 ， 在 代理 对 


象 中 除了 调用 站 实 对 象 的 商务 信息 查询 功能 外 ， 还 增加 了 身份 验证 和 日 志 记 录 等 功能 。 使 用 
代理 模式 设计 该 商务 信息 查询 系统 ， 结 构图 如 图 15-4 所 示 。 
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ER Searcher 






+ DoSearch (string userld, stnng keyword) : string 


A 




















、 RealSearcher 


+ DoSearch (string userld, stnng keyword) : string 







- Searcher : RealSearcher 

- validator : AccessValidator 

-logger :Logger 

+ DoSearch (string userld, string keyword) : stnng 

+ Validate (stnng userld) : bool 

+ Log (string userld) :void 
中 












AccessValidator Logger 
+ Validate (string userld) : bool + Log (string userld) :void 


图 15-4 商务 信息 查询 系统 结构 图 


在 图 15-4 中 ， 业 务 类 AccessValidator 用 于 验证 用 户 身份 ， 业 务 类 Logger 用 于 记录 用 户 查 询 日 
志 ，Searcher 充 当 抽 和 象 主题 角色 ，RealSearcher 充 当 站 实 主题 角色 ，ProxySearcher 充 当代 理 主 题 
角色 。 


1. 实例 代码 
(1) AccessValidator : 身份 验证 类 ， 业 务 类 ， 它 提供 方法 Validate() 来 实现 身份 验证 。 


//AccessValidator.cs 
using System; 


namespace ProxySample 


{ 
class AccessValidator 
// 模 拟 实现 登录 验证 
public bool Validate(string userId) 
{ 
Console.WriteLine(" 在 数据 库 中 验证 用 户 '" + userId + "' 是 否 是 合 
if (userId.Equals(" 杨 过 ")) f{ 
Console.WwriteLine("'{0}' 登 录 成 功 !",userId); 
return true; 
} 
else { 
Console.WwriteLine("'{0}' 登 录 失 败 1"，UuserId); 
return false,; 
} 
} 
} 
} 


(2) Logger : 日 志 记 录 类 ， 业 务 类 ， 它 提供 方法 Log() 来 保存 日 志 。 
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//Logger.cs 
Using System; 


namespace ProxySample 


{ 
class Logger 
// 模 拟 实现 日 志 记 录 
public void Log(string userId) { 
Console .WriteLine(" 更 新 数据 库 ， 用户 '{0}' 查询 次 数 加 1 1! ",userId 
} 
} 
} 


(3) Searcher : 抽象 查询 类 ， 充 当 抽 象 主题 角色 ， 它 声明 了 DoSearch() 方 法 。 


//Searcher .cs 
namespace ProxySample 


{ 
interface Searcher 
{ 
string DoSearch(string userId, string keyword); 
} 
} 


(4) RealSearcher : 具体 查询 类 ， 充 当 旦 实 主题 角色 ， 它 实现 查询 功能 ， 提 供 方法 DoSearch() 来 
查询 信息 。 


//RealSearcher.cs 
Using System; 


namespace ProxySample 


{ 
class RealSearcher : Searcher 
// 模 拟 查 询 商 务 信 息 
public string DoSearch(string userId, string keyword) { 
Console.WwriteLine(" 用 户 '{0}' 使 用 关键 词 ' {1}' 查询 商务 信息 1!", us 
return "返回 具体 内 容 "'， 
} 
} 
} 


(5) ProxySearcher : 代理 查询 类 ， 充 当代 理 主题 角色 ， 它 是 查询 代理 ， 维 持 了 对 RealSearcher 对 
象 、AccessValidator 对 象 和 Logger 对 象 的 引用 。 


//ProxySearcher.cs 
namespace ProxySample 
{ 
class ProxySearcher : Searcher 
{ 
private RealSearcher searcher = new RealSearcher(); // 维 持 一 个 
private AccessValidator validator; 
private Logger logger; 
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public string DoSearch(string USserId，string keyword ) 


{ 
// 如 果 身 份 验证 成 功 ， 则 执行 查询 
if (this.Validate(userId)) 
{ 
string result = searcher.DoSearch(userId, keyword);. 
this.Log(userId); // 记 录 查 询 日 志 
return result; // 返 回 查询 结果 
} 
else 
{ 
return null; 
} 
} 


// 创 建 访问 验证 对 象 并 调用 其 Validate() 方 法 实现 身份 验证 
public bool Validate(string USserId ) 
{ 

validator = new AccessValidator(); 

return validator.Validate(userId); 


} 


// 创 建 日 志 记 录 对 象 并 调用 其 Log( ) 方 法 实现 日 志 记 录 
public void Log(string UserId ) 
{ 

logger = new Logger(); 

logger .Log(userId); 


} 
(6) 配置 文件 App.config， 在 配置 文件 中 存储 了 代理 主题 类 类 名 。 


<?xml1 version="1.0" encoding="utf-8" ?> 
<configuration> 
<appSettings> 
<add key="proxy" value="ProxySample.ProxySearcher"/> 
</appSettings> 
</configuration> 


(7) Program : 客户 端 测试 类 


//Program.cs 

Using System; 

Using System.Configuration; 
Using System.Reflection,; 


namespace ProxySample 


{ 


class Program 


{ 


static void Main(string[] args) 


{ 
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// 读 取 配 置 文件 
string proxy = ConfigurationManager.AppSettings["proxy"] 


// 反 射 生成 对 和 象 ， 针 对 抽象 编程 ， 客 户 端 无 须 分 辨 商 实 主 题 类 和 代理 类 
Searcher searcher; 
searcher = (Searcher)Assembly.Load("ProxySample").Create 


String result = Searcher .DoSearch(" 杨 过 "， "玉女 心经 " ) ; 
Console.Read( ); 


编译 并 运行 程序 ， 输 出 结果 如 下 : 


在 数据 库 中 验证 用 户 ' 杨 过 ' 是 否 是 合法 用 户 ? 

! 杨 过 ' 登录 成 功 |! 

用 户 ' 杨 过 ' 使 用 关键 词 ' 玉 女 心经 ' 查询 商务 信息 ! 
更 新 数据 库 ， 用 户 ' 杨 过 ' 查询 次 数 加 1 1 


本 实例 是 保护 代理 和 智能 引用 代理 的 应 用 实例 ， 在 代理 类 ProxySearcher 中 实现 对 丨 实 主题 类 的 
权限 控制 和 引用 计数 ， 如 果 需 要 在 访问 丨 实 主题 时 增加 新 的 访问 控制 机 制 和 新 功能 ， 只 需 增 
加 一 个 新 的 代理 类 ， 再 修改 配置 文件 ， 在 客户 端 代码 中 使 用 新 增 代 理 类 即 可 ， 源 代码 无 须 修 
改 ， 符 合 开 闭 原则 。 
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设计 模式 之 代理 模式 (三 ) 
设计 模式 之 代理 模式 (三 ) 
15.4 远程 代理 


远程 代理 (Remote Proxy) 是 一 种 常用 的 代理 模式 ， 它 使 得 客户 端 程序 可 以 访问 在 远程 主机 上 的 
对 象 ， 远 程 主机 可 能 具有 更 好 的 计算 性 能 与 处 理 速 度 ， 可 以 快速 响应 并 处 理 客户 端的 请 求 。 
远程 代理 可 以 将 网 络 的 细节 隐藏 起 来 ， 使 得 客户 端 不 必 考 虑 网 络 的 存在 。 客 户 端 完 全 可 以 认 
为 被 代理 的 远程 业务 对 象 是 在 本 地 而 不 是 在 远程 ， 而 远程 代理 对 象 承担 了 大 部 分 的 网 络 通信 
工作 ， 并 负责 对 远程 业务 方法 的 调用 。 


远程 代理 示意 图 如 图 15-5 所 示 ， 客 户 端 对 象 不 能 直接 访问 远程 主机 中 的 业务 对 象 ， 只 能 采取 间 
接 访问 的 方式 。 远 程 业务 对 象 在 本 地 主机 中 有 一 个 代理 对 象 ， 该 代理 对 象 负责 对 远程 业务 对 
象 的 访问 和 网 络 通信 ， 它 对 于 客户 端 对 象 而 言 是 透明 的 。 客 户 端 无 须 关心 实现 具体 业务 的 是 
谁 ， 只 需要 按照 服务 接口 所 定义 的 方式 直接 与 本 地 主机 中 的 代理 对 象 交互 即 可 。 





图 15-5 远程 代理 示意 图 


在 基于 .NET 平 台 的 分 布 式 技术 ， 例 如 DCOM(Distribute Component Object Model， 分 布 式 组 件 
对 象 模型 )、Web Service 中 ， 都 应 用 了 远程 代理 模式 ， 大 家 可 以 查阅 相关 资料 进行 扩展 学 习 。 


15.5 虚拟 代理 


虚拟 代理 (Virtual Proxy) 也 是 一 种 常用 的 代理 模式 ， 对 于 一 些 占 用 系统 资源 较 多 或 者 加 载 时 间 
较 长 的 对 象 ， 可 以 给 这 些 对 象 提供 一 个 虚拟 代理 。 在 站 实 对 象 创建 成 功 之 前 虚拟 代理 扮演 旧 
实 对 象 的 替身 ， 而 当 申 实 对 象 创建 之 后 ， 虚 拟 代理 将 用 户 的 请 求 转发 给 丨 实 对 象 。 


通常 ， 在 以 下 两 种 情况 下 可 以 考虑 使 用 虚拟 代理 : 


(1) 由 于 对 象 本 身 的 复杂 性 或 者 网 络 等 原因 导致 一 个 对 象 需要 较 长 的 加 载 时 间 ， 此 时 可 以 用 一 
个 加 载 时 间 相 对 较 短 的 代理 对 象 来 代表 真实 对 象 。 通 常 在 实现 时 可 以 结合 多 线程 技术 ， 一 个 
线程 用 于 显示 代理 对 象 ， 其 他 线程 用 于 加 载 站 实 对 象 。 这 种 虚拟 代理 模式 可 以 应 用 在 程序 局 
动 的 时 候 ， 由 于 创建 代理 对 象 在 时 间 和 处 理 复杂 度 上 要 少 于 创建 盖 实 对 象 ， 因 此 ， 在 程序 启 
动 时 ， 可 以 用 代理 对 象 代 蔡 丨 实 对 象 初始 化 ， 大 大 加 速 了 系统 的 启动 时 间 。 当 需要 使 用 昌 实 
对 象 时 ， 再 通过 代理 对 象 来 引用 ， 而 此 时 真实 对 象 可 能 已 经 成 功 加 载 完 毕 ， 可 以 缩短 用 户 的 
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等 待 时 间 。 


(2) 当 一 个 对 象 的 加 载 十 分 耗费 系统 资源 的 时 候 ， 也 非常 适合 使 用 虚拟 代理 。 虚 拟 代理 可 以 让 
那些 占用 大 量 内 存 或 处 理 起 来 非常 复杂 的 对 象 推迟 到 使 用 它们 的 时 候 才 创 建 ， 而 在 此 之 前 用 
一 个 相对 来 说 占用 资源 较 少 的 代理 对 象 来 代表 丨 实 对 象 ， 再 通过 代理 对 象 来 引用 站 实 对 象 。 
为 了 节省 内 存 ， 在 第 一 次 引用 昌 实 对 象 时 再 创建 对 象 ， 并 且 该 对 象 可 被 多 次 重用 ， 在 以 后 每 
次 访问 时 需要 检测 所 需 对 象 是 否 已 经 被 创建 ， 因此 在 访问 该 对 象 时 需要 进行 存在 性 检测 ， 这 
需要 消耗 一 定 的 系统 时 间 ， 但 是 可 以 节省 内 存 空间 ， 这 是 一 种 用 时 间 换 取 空 间 的 做 法 。 


无 论 是 以 上 哪 种 情况 ， 座 拟 代理 都 是 用 一 个 “虚假 "的 代理 对 象 来 代表 莫 实 对 象 ， 通 过 代理 对 象 
来 间接 引用 趴 实 对 象 ， 可 以 在 一 定 程 度 上 提高 系统 的 性 能 。 


15.6 缓冲 代理 


组 冲 代 理 (Cache proxy) 也 是 一 种 较为 常用 的 代理 楼 式 ， 它 为 茉 一 个 操作 的 结果 提供 临时 的 缓存 
存储 空间 ， 以 便 在 后 续 使 用 中 能 够 共享 这 些 结果 ， 从 而 可 以 避免 某 些 方法 的 重复 执行 ， 优 化 
系统 性 能 。 


在 微软 示例 项 目 PetShop 4.0 的 业务 逻辑 层 (Business Logic Layer, BLL) 中 定义 了 Product、 
Category、 Item 等 类 ， 它 们 封装 了 相关 的 业务 方法 ， 用 于 调用 数据 访问 层 (Data Access Layer, 
DAL) 对 象 访问 数据 库 ， 以 获取 相关 数据 。 为 了 改进 系统 性 能 ， PetShop 4. 0 为 这 些 实现 方法 增 
加 缓存 机 制 ， 引 入 一 个 新 的 对 象 去 控 箱 | 原来 的 BLL 业 务 远 辑 对 象 ， 这 些 新 的 对 象 对 应 于 代理 模 
式 中 的 代理 对 象 。 在 引入 代理 模式 后 ， 实 现 了 在 缓存 级 别 上 对 业务 对 象 的 封装 ， 增 强 了 对 业 
务 对 象 的 控制 ， 如 果 需 要 访问 的 数据 在 缓存 中 已 经 存在 ， 则 无 须 再 重复 执行 获取 数据 的 方 

法 ， 直 接 返 回 存储 在 缕 存 中 的 数据 即 可 。 由 于 原 有 业务 对 象 〈 拓 实 对 象 ) 和 新 增 代理 对 象 暴 
露 在 外 的 方法 是 一 致 的 ， 因 而 对 于 调用 方 即 客户 端 而 言 ， 调 用 代理 对 象 与 趴 实 对 象 并 没有 实 
质 的 区 别 。 

这 些 新 引入 的 代理 类 包括 ProductDataProxy 、 CategoryDataProxy 和 ItemDataProxy 等 。 下 面 以 
PetShop.BLL.Product 业 务 对 象 为 例 进行 说 明 ，PetShop 4.0 为 其 建立 了 代理 对 象 


ProductDataProxy ， 并 在 ProductDataProxy 的 GetProductsByCategory() 方 法 中 调用 了 业务 逻辑 层 
Product 类 的 GetProductsByCategory() 方 法 ， 同 时 增加 了 缓存 机 制 。 如 图 15-6 所 示 : 


ProductDataProxy 


+ GetProductsByCategory (string category) : IList 
+ GetProductsBySearch (String text) : IList 
+ GetProduct (strng productld) :Productlinfo 


+ GetProductsByCategory (string category) : IList 
+ GetProductsBySearch (string text) : |List 
+ GetProduct (stnng productld) : Productinfo 





图 15-6 PetShop4.0 缓 存 代理 示意 图 
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设计 模式 之 代理 模式 (三 ) 


在 ProductDataProxy 类 中 存在 如 下 代码 片段 : 


public static class ProductDataProxy 


二 


int,Parse(Configura 
bool.Parse(Configur: 


private static readonly int productTimeout 
private static readonly bool enableCaching 


public static IList GetProductsByCategory(string category) 
{ 


Product product = new Product(); 


// 如 果 缓 存 被 禁用 ， 则 直接 通过 product 对 象 来 获取 数据 
if (!enableCaching) 
{ 


} 


string key = "product_by_category_" + category; 
// 从 缓存 中 获取 数据 
IList data = (IList )HttpRuntime.Cache[key]; 


return product.GetProductsByCategory(category); 


// 如 果 缓 存 中 没有 数据 则 执行 如 下 代码 
if (data == null) 
{ 
data = product.GetProductsByCategory(category); 
// 通 过 工厂 创建 AggregateCacheDependency 对 象 
AggregateCacheDependency cd = DependencyFacade .GetProduc 
// 将 数据 存储 在 缓存 中 ， 并 添加 必要 的 AggregateCcacheDependency 对 象 
HttpRuntime.Cache.Add(key, data, cd, DateTime.Now.AddHou 
} 


return data; 


在 上 述 代码 中 ，AggregateCacheDependency 是 从 .NET Framework 2.0 开 始 新 增 的 一 个 类 ， 它 负 
责 监 视 依赖 项 对 象 的 集合 。 当 这 个 集合 中 的 任意 一 个 依赖 项 对 象 发 生 改变 时 ， 该 依赖 项 对 象 
对 应 的 缓存 对 象 都 将 被 自动 移 除 。 在 此 不 对 AggregateCacheDependency 进 行 详细 说 明 ， 大 家 可 
以 查阅 相关 资料 进行 扩展 学 习 。 


与 业务 逻辑 层 Product 对 象 的 GetProductsByCategory() 方 法 相 比 ， 上 述 代码 增加 了 缓存 机 制 。 当 
缓存 内 不 存在 相关 数据 项 时 ， 则 直接 调用 业务 逻辑 层 Product 的 GetProductsByCategory() 方 法 来 
获取 数据 ， 并 将 其 与 对 应 的 AggregateCacheDependency 对 象 一 起 存储 在 缓存 中 。 在 
ProductDataProxy 类 的 每 一 个 业务 方法 中 都 实例 化 了 Product 类 ， 再 调用 Product 类 的 相应 方法 ， 
此 ProductDataProxy 与 Product 之 间 属 于 依赖 关系 ， 这 是 标准 代理 模式 的 一 种 变形 ， 可 以 按照 
标准 代理 模式 对 其 进行 改进 ， 包 括 引 入 高 层 的 抽象 接口 。 
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设计 模式 之 代理 模式 (四 ) 


bg ey 2 a 、 2 ~ 

设计 模式 之 代理 模式 (四 ) 

、` 几 全 2 a 、 2 > 

设计 模式 之 代理 模式 (四 ) 

15.7 代理 模式 效果 与 适用 场景 

代理 模式 是 常用 的 结构 型 设计 模式 之 一 ， 它 为 对 象 的 间接 访问 提供 了 一 个 解决 方案 ， 可 以 对 
对 象 的 访问 进行 控制 。 代 理 模 式 类 型 较 多 ， 其 中 远程 代理 、 虚 拟 代理 、 保 护 代理 等 在 软件 开 
发 中 应 用 非常 广泛 。 

15.7.1 模式 优点 

代理 模式 的 共同 优点 如 下 : 

(1) 能 够 协调 调用 者 和 被 调用 者 ， 在 一 定 程度 上 降低 了 系统 的 耦合 度 。 


(2) 客户 端 可 以 针对 抽象 主题 角色 进行 编程 ， 增 加 和 更 换代 理 类 无 须 修改 源 代码 ， 符 合 开 闭 原 
则 ， 系 统 具有 较 好 的 灵活 性 和 可 扩展 性 。 


此 外 ， 不 同类 型 的 代理 模式 也 具有 独特 的 优点 ， 例 如 : 


(1) 远程 代理 为 位 于 两 个 不 同 地 址 空间 对 象 的 访问 提供 了 一 种 实现 机 制 ， 可 以 将 一 些 消耗 资源 
较 多 的 对 象 和 操作 移 至 性 能 更 好 的 计算 机 上 ， 提 高 系统 的 整体 运行 效率 。 


(2) 虚拟 代理 通过 一 个 消耗 资源 较 少 的 对 象 来 代表 一 个 消耗 资源 较 多 的 对 象 ， 可 以 在 一 定 程度 
上 节省 系统 的 运行 开销 。 


(3) 缓冲 代理 为 某 一 个 操作 的 结果 提供 临时 的 缓存 存储 空间 ， 以 便 在 后 续 使 用 中 能 够 共享 这 些 
结果 ， 优 化 系统 性 能 ， 缩 短 执行 时 间 。 


(4) 保护 代理 可 以 控制 对 一 个 对 象 的 访问 权限 ， 为 不 同 用 户 提供 不 同 级 别 的 使 用 权限 。 
15.7.2 模式 缺点 
代理 模式 的 主要 缺点 如 下 : 


(1) 由 于 在 客户 端 和 监 实 主题 之 间 增 加 了 代理 对 象 ， 因 此 有 些 类 型 的 代理 模式 可 能 会 造成 请 求 
的 处 理 速度 变 慢 ， 例 如 保护 代理 。 


(2) 实现 代理 模式 需要 额外 的 工作 ， 而 且 有 些 代 理 模式 的 实现 过 程 较为 复杂 ， 例 如 远程 代理 。 
15.7.3 模式 适用 场景 

代理 模式 的 类 型 较 多 ， 不 同类 型 的 代理 模式 有 不 同 的 优 缺 点 ， 它 们 应 用 于 不 同 的 场合 : 

(1) 当 客户 端 对 象 需要 访问 远程 主机 中 的 对 象 时 可 以 使 用 远程 代理 。 


(2) 当 需 要 用 一 个 消耗 资源 较 少 的 对 象 来 代表 一 个 消耗 资源 较 多 的 对 象 ， 从 而 降低 系统 开销 、 
缩短 运行 时 间 时 可 以 使 用 虚拟 代理 ， 例 如 一 个 对 象 需 要 很 长 时 间 才 能 完成 加 载 时 。 


(3) 当 需 要 为 某 一 个 被 频繁 访问 的 操作 结果 提供 一 个 临时 存储 空间 ， 以 供 多 个 客户 端 共 享 访问 
这 些 结果 时 可 以 使 用 缓冲 代理 。 通 过 使 用 缓冲 代理 ， 系 统 无 须 在 客户 端 每 一 次 访问 时 都 重新 
执行 操作 ， 只 需 直 接 从 临时 缓冲 区 获取 操作 结果 即 可 。 
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设计 模式 之 代理 模式 (四 ) 


(4) 当 需 要 控制 对 一 个 对 象 的 访问 ， 为 不 同 用 户 提供 不 同 级 别 的 访问 权限 时 可 以 使 用 保护 代 
理 。 


(5) 当 需 要 为 一 个 对 象 的 访问 (引用 ) 提供 一 些 额外 的 操作 时 可 以 使 用 智能 引用 代理 。 
习题 
1. Windows 操 作 系 统 中 的 应 用 程序 快捷 方式 是 ( ) 模 式 的 应 用 实例 。 
A. 代理 (Proxy) B. 组 合 (Composite) 
C. 装饰 (Decorator) D. 外 观 (Facade) 
1. 毕业 生 通过 职业 介绍 所 找 工 作 ， 请 问 该 过 程 蕴 含 了 哪 种 设计 模式 ， 绘 制 相应 的 类 图 。 


2. 在 某 应 用 软件 中 需要 记录 业务 方法 的 调用 日 志 ， 在 不 修改 现 有 业务 类 的 基础 上 为 每 一 个 
类 提供 一 个 日 志 记 录 代 理 类 ， 在 代理 类 中 输出 日 志 ， 如 在 业务 方法 Method(O 调 用 之 前 输 
出 “方法 Method() 被 调用 ， 调 用 时 间 为 2012-11-5 10:10:10”， 调 用 之 后 如 果 没 有 抛 异 常 则 
输出 “方法 MethodO 调 用 成 功 ”， 否 则 输出 “方法 Method0O 调 用 失败 ”。 在 代理 类 中 调用 晶 实 
业务 类 的 业务 方法 ， 使 用 代理 模式 设计 该 日 志 记录 模块 的 结构 ， 绘 制 类 图 并 使 用 C# 语 言 
编程 模拟 实现 。 


3. 某 软件 公司 欲 开 发 一 款 基于 C/S 的 网 络 图 片 查 看 器 ， 具 体 功 能 描述 如 下 : 用 户 只 需 在 图 
片 查看 器 中 输入 网 页 URL ， 程 序 将 自动 将 该 网 页 所 有 图 片 下 载 到 本 地 ， 考 虑 到 有 些 网 页 
图 片 比较 多 ， 而 且 某 些 图 片 文件 比较 大 ， 因 此 将 先 以 图 标的 方式 显示 图 片 ， 不 同类 型 的 
图 片 使 用 不 同 的 图 标 ， 并 且 在 图 标 下 面 标注 该 图 片 的 文件 名 ， 用 户 单 击 图 标 后 可 查看 旧 
正 的 图 片 ， 界 面 效果 如 图 15-7 所 示 。 试 使 用 虚拟 代理 模式 设计 并 实现 该 图 片 查看 器 。 

( 注 : 可 以 结合 多 线程 机 制 ， 使 用 一 个 线程 显示 小 图 标 ， 同 时 启动 另 一 个 线程 在 后 台 加 
载 原 图 。) 


图 片 查 看 器 


原 图 显示 


Ea Ph 
全 


请 输入 网 页 URL: 


| 
| 


logo.gif yangguo.gif jinyong.gif bg.jpg xiaolongnv.jpg 


大 局 六 


top.jpg ad.gif wuxia.bmp 





图 15-7 图 片 查 看 器 界面 效果 图 
【友情 提示 : 建议 大 家 有 时 间 的 话 把 这 些 练习 都 做 一 做 ， 有 问题 欢迎 讨论 ! 】 
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十 一 个 行为 型 模式 


十 一 个 行为 型 模式 
十 一 个 行为 型 模式 


。 十 一 个 行为 型 模式 
o 职 页 责 链 模 式 -Chain of Responsibility Pattern 


O 











O 


解释 器 模式 -Interpreter Pattern 


sm 自 宝 二 是 二 的 实现 一 和 














国 
国 
图 
国 
国 
o 迭代 器 
= 
国 人 
和 遍历 聚合 对 象 中 的 元 素 入 代 器 模式 四 
四 遍历 聚合 对 象 中 的 元 素 一 和 迭代 器 模式 (五 
@ 遍历 聚合 对 象 中 的 元 素 - ”和 迭代 器 模式 (六 
o 二 者 模式 -Mediator Pattern 


协调 多 个 对 象 之 间 的 交互 ”中 介 者 模式 
协调 多 个 对 外 之 间 的 交互 -中介 者 模式 








协调 多 个 对 象 之 间 的 交互 一 一 中 介 者 模式 








协调 多 个 对 象 之 间 的 交互 ”中 介 者 模式 (四 

协调 多 个 对 象 之 间 的 交互 ”中 介 者 模式 (五 
忘 录 模 式 -Memento Pattern 

撤销 功能 的 实现 备忘录 模式 (一 

撤销 功能 的 实现 备忘录 模式 











撤销 功能 的 实现 一 备忘录 模式 








撤销 功能 的 实现 备忘录 模式 (四 
撤销 功能 的 实现 备忘录 模式 (五 
o 观察 者 模式 -Observer Pattern 

对 象 间 的 联动 观察 者 模式 

对 象 间 的 联动 ”观察 者 模式 

对 象 间 的 联动 
对 象 间 的 联动 


Oo 
Ey 
Week 





察 








观察 者 模式 (三 
观察 者 模式 (四 
五 














对 象 间 的 联动 一 一 观察 者 模式 





对 象 间 的 联动 一 一 观察 者 模式 〈 六 
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十 一 个 行为 型 样 起 


o 状态 模式 -State Pattern 
上 处 理 对 象 的 多 种 状态 及 其 相互 转换 -状态 模式 
上 处 理 对 象 的 多 种 状态 及 其 相互 转换 -状态 模式 








处 理 对 象 的 多 种 状态 及 其 相互 转换 一 一 状态 模式 〈 三 
处 理 对 象 的 多 种 状态 及 其 相互 转换 一 一 状态 模式 〈 四 
次 








处 理 对 象 的 多 种 状态 及 其 相互 转换 一 一 状态 模式 
处 理 对 象 的 多 种 状态 及 其 相互 转换 一 一 状态 模式 〈 六 








o 策略 模式 -Strategy Pattern 
@ 算法 的 封装 与 切换 策略 模式 








o 模板 方法 模式 -Template Method Pattern 
m 模板 方法 模式 深度 解析 (一 
四 模板 方法 模式 深度 解析 (二 ) 
m 模板 方法 模式 深度 解析 (三 

o 访问 者 模式 -Visitor Pattern 
@ 操作 复杂 对 象 结构 
m 操作 复杂 对 象 结构 
@ 操作 复杂 对 象 结构 
m 操作 复杂 对 象 结构 


访问 者 模式 
访问 者 模式 




















访问 者 模式 (三 
访问 者 模式 (四 
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职责 链 模式 -Chain of Responsibility Pattern 


职 贡 链 模式 -Chain of Responsibility Pattern 


职责 链 模式 -Chain of Responsibility Pattern 【学 习 难 度 : 友 友 友 六 交 ， 使 用 频率 : 姆 丰 交 六 六 】 
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请 求 的 链 式 处 理 职责 链 模 式 (一 ) 


br 


请 求 的 链 式 处 理 - 职责 链 模 式 (一 ) 
请 求 的 链 式 处 理 - 职责 链 模式 (一 ) 


“一 对 二 ”，“ 过 ”，“ 过 ”..…. 这 声音 熟悉 吗 ? 你 会 想到 什么 ? 对 ! 纸牌 。 在 类 似 “ 斗 地 主 ” 这 样 的 
纸牌 游戏 中 ， 某 人 出 牌 给 他 的 下 家 ， 下 家 看 看 手中 的 牌 ， 如 果 要 不 起 上 家 的 牌 则 将 出 牌 请 求 

再 转发 给 他 的 下 家 ， 其 下 家 再 进行 判断 。 一 个 循环 下 来 ， 如 果 其 他 人 都 要 不 起 该 牌 ， 则 最 初 

的 出 牌 者 可 以 打出 新 的 牌 。 在 这 个 过 程 中 ， 上 牌 作为 一 个 请 求 沿 着 一 条 链 在 传递 ， 每 一 位 纸牌 

的 玩家 都 可 以 处 理 该 请 求 。 在 设计 模式 中 ， 我 们 也 有 一 种 专门 用 于 处 理 这 种 请 求 链 式 传递 的 

模式 ， 它 就 是 本 章 将 要 介绍 的 职责 链 模式 。 


启 


16.1 采购 单 的 分 级 审批 


Sunny 软 件 公司 承接 了 某 企 业 SCM(Supply Chain Management， 供 应 链 管理 ) 系 统 的 开发 任务 ， 

其 中 包含 一 个 采购 审批 子 系统 。 该 企业 的 采购 审批 是 分 级 进行 的 ， 即 根据 采购 金额 的 不 同 由 

不 同 层次 的 主管 人 员 来 审批 ， 主 任 可 以 审批 5 万 元 以 下 (不 包括 5 万 元 ) 的 采购 单 ， 副 董事 长 

可 以 审批 5 万 元 至 10 万 元 (不 包括 10 万 元 ) 的 采购 单 ， 董 事 长 可 以 审批 10 万 元 至 50 万 元 (不 包 
括 50 万 元 ) 的 采购 单 ，50 万 元 及 以 上 的 采购 单 就 需要 开 董 事 会 讨论 决定 。 如 图 16-1 所 示 : 


金 疾 二 5 万 元 5 万 元 < 金 疾 三 10 万 元 。 10 万 元 < 金 疾 三 50 万 元 爹 和 =50 万 元 





图 16-1 采购 单 分 级 审批 示意 图 


如 何在 软件 中 实现 采购 单 的 分 级 审批 ? Sunny 软 件 公 司 开发 人 员 提 出 了 一 个 初始 解决 方案 ， 在 
系统 中 提供 一 个 采购 单 处 理 类 PurchaseRequestHandler 用 于 统一 处 理 采 购 单 ， 其 框架 代码 如 下 
所 示 : 


// 采 购 单 处 理 类 
class PurchaseRequestHandler { 
// 递 交 采 购 单 给 主任 
public void sendRequestToDirector(PurchaseRequest request) { 
if (request.getAmount() < 50000) { 
// 主 任 可 审批 该 采购 单 
this.handleByDirector(request); 


} 

else if (request.getAmount() < 100000) { 
// 副 董事 长 可 审批 该 采购 单 
this.handleByVicePresident(request); 

} 

else if (request.getAmount() < 500000) { 
// 董 事 长 可 审批 该 采购 单 
this.handleByPresident(request); 
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else { 
// 董 事 会 可 审批 该 采购 单 
this.handleByCongress(request); 


} 


// 主 任 审批 采购 单 

public void handleByDirector(PurchaseRequest request) { 
// 代 码 省 略 

} 


// 副 董事 长 审批 采购 单 

public void handleByVicePresident(PurchaseRequest request) { 
// 代 码 省 略 

} 


// 董 事 长 审批 采购 单 

public void handleByPresident(PurchaseRequest request ) { 
// 代 码 省 略 

} 


// 董 事 会 审批 采购 单 

public void handleByCongress(PurchaseRequest request) { 
// 代 码 省 略 

} 


} 
问题 貌似 很 简单 ， 但 仔细 分 析 ， 发 现 上 述 方案 存在 如 下 几 个 问题 : 


(1D)PurchaseRequestHandler 类 较为 庞大 ， 各 个 级 别 的 审批 方法 都 集中 在 一 个 类 中 ， 违 反 了 “单一 
职责 原则 ”， 测 试 和 维护 难度 大 。 


(2) 如 果 需 要 增加 一 个 新 的 审批 级 别 或 调整 任何 一 级 的 审批 金额 和 审批 细节 (例如 将 董事 长 的 
审批 额度 改 为 60 万 元 ) 时 都 必须 修改 源 代码 并 进行 严格 测试 ， 此 外 ， 如 果 需 要 移 除 茶 一 级 别 
(例如 金额 为 10 万 元 及 以 上 的 采购 单 直接 由 董事 长 审批 ， 不 再 设 副 董事 长 一 职 ) 时 也 必须 对 
源 代码 进行 修改 ， 违 反 了 “ 开 闭 原则 ”。 


(3) 审 批 流程 的 设置 缺乏 灵活 性 ， 现 在 的 审批 流程 是 “主任 --> 副 董事 长 --> 董 事 长 --> 董 事 会 ”， 如 
果 需 要 改 为 “主任 --> 董 事 长 --> 董 事 会 ” » 在 此 方案 中 只 能 通过 修改 源 代 码 来 实现 2 客户 端 无 法 
定制 审批 流程 。 


如 何 针 对 上 述 问题 对 系统 进行 改进 ? Sunny 公 司 开发 人 员 迫 切 需要 一 种 新 的 设计 方案 ， 还 好 有 


职责 链 模式 ， 通 过 使 用 职责 链 模 式 我 们 可 以 最 大 程度 地 解决 这 些 问题 ， 下 面 让 我 们 正式 进入 
职责 链 模式 的 学 习 。 
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16.2 职责 链 模式 概 述 


很 多 情况 下 ， 在 一 个 软件 系统 中 可 以 处 理 某 个 请 求 的 对 象 不 止 一 个 ， 例 如 SCM 系 统 中 的 采购 
单 审批 ， 主 任 、 副 董事 长 、 董 事 长 和 董事 会 都 可 以 处 理 采购 单 ， 他 们 可 以 构成 一 条 处 理 采 购 
单 的 链 式 结构 ， 采 购 单 沿 着 这 条 链 进 行 传递 ， 这 条 链 就 称 为 职责 链 。 职 责 链 可 以 是 一 条 直 

线 、 一 个 环 或 者 一 个 树 形 结构 ， 最 常见 的 职责 链 是 直线 型 ， 即 沿 着 一 条 单 向 的 链 来 传递 请 
求 。 链 上 的 每 一 个 对 象 都 是 请 求 处 理 者 ， 职 责 链 模式 可 以 将 请 求 的 处 理 者 组 织 成 一 条 链 ， 并 
让 请 求 沿 着 链 传递 ， 由 链 上 的 处 理 者 对 请 求 进行 相应 的 处 理 ， 客 户 端 无 须 关 心 请 求 的 处 理 细 
节 以 及 请 求 的 传递 ， 只 需 将 请 求 发 送 到 链 上 即 可 ， 实 现 请 求 发 送 者 和 请 求 处 理 者 解 耦 。 
职责 链 模式 定义 如 下 : 职责 链 模式 (Chain of Responsibility Pattern) : 避免 请 求 发 送 者 与 接收 者 
耦合 在 一 起 ， 让 多 个 对 象 都 有 可 能 接收 请 求 ， 将 这 些 对 象 连接 成 一 条 链 ， 并 且 沿 着 这 条 链 传 
递 请 求 ， 直 到 有 对 象 处 理 它 为 止 。 职 责 链 模 式 是 一 种 对 象 行为 型 模式 。 


职责 链 模式 结构 的 核心 在 于 引入 了 一 个 抽象 处 理 者 。 职 责 链 模 式 结构 如 图 16-2 所 示 : 











Handler 


+ handleRequest () 





ConcreteHandlerA 
+ handleRequest () 


16-2 职责 链 模 式 结构 图 。 
在 职责 链 模 式 结构 图 中 包含 如 下 几 个 角色 : 





ConcreteHandlerB 
+ handleRequest () 





e@ Handler (抽象 处 理 者 ) : 它 定 义 了 一 个 处 理 请 求 的 接口 ， 一 般 设 计 为 抽象 类 ， 由 于 不 同 的 
具体 处 理 者 处 理 请 求 的 方式 不 同 ， 因 此 在 其 中 定义 了 抽象 请 求 处 理 方法 。 因 为 每 一 个 处 理 者 
的 下 家 还 是 一 个 处 理 者 ， 因 此 在 抽象 处 理 者 中 定义 了 一 个 抽象 处 理 者 类 型 的 对 象 (如 结构 图 
中 的 successor) ， 作 为 其 对 下 家 的 引用 。 通 过 该 引用 ， 处 理 者 可 以 连 成 一 条 链 。 
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e@ ConcreteHandler (有 具体 处 理 者 ) : 它 是 抽象 处 理 者 的 子 类 ， 可 以 处 理 用 户 请 求 ， 在 具体 处 理 
者 类 中 实现 了 抽象 处 理 者 中 定义 的 抽象 请 求 处 理 方法 ， 在 处 理 请 求 之 前 需要 进行 判断 ， 看 是 
和 否 有 相应 的 处 理 权限 ， 如 果 可 以 处 理 请 求 就 处 理 它 ， 否 则 将 请 求 转 发 给 后 继 者 ; 在 具体 处 理 
者 中 可 以 访问 链 中 下 一 个 对 象 ， 以 便 请 求 的 转发 。 


在 职责 链 模式 里 ， 很 多 对 象 由 每 一 个 对 象 对 其 下 家 的 引用 而 连接 起 来 形成 一 条 链 。 请 求 在 这 
个 链 上 传递 ， 直 到 链 上 的 某 一 个 对 象 决定 处 理 此 请 求 。 发 出 这 个 请 求 的 客户 端 并 不 知道 链 上 
的 哪 一 个 对 象 最 终 处 理 这 个 请 求 ， 这 使 得 系统 可 以 在 不 影响 客户 端的 情况 下 动态 地 重新 组 织 
链 和 分 配 责 任 。 


职责 链 模 式 的 核心 在 于 抽象 处 理 者 类 的 设计 ， 抽 和 象 处 理 者 的 典型 代码 如 下 所 示 : 


abstract class Handler { 
// 维 持 对 下 家 的 引用 
protected Handler successor; 


public void setSuccessor(Handler successor) { 
this.successor=successor; 
} 


public abstract void handleRequest(String request); 


} 


上 述 代码 中 ， 抽 象 处 理 者 类 定义 了 对 下 家 的 引用 对 象 ， 以 便 将 请 求 转发 给 下 家 ， 该 对 象 的 访 
问 符 可 设 为 protected， 在 其 子 类 中 可 以 使 用 。 在 抽象 处 理 者 类 中 声明 了 抽象 的 请 求 处理 方 法 ， 
具体 实现 交 由 子 类 完成 。 


具体 处 理 者 是 抽象 处 理 者 的 子 类 ， 它 具有 两 大 作用 : 第 一 是 处 理 请 求 ， 不 同 的 具体 处 理 者 以 
不 同 的 形式 实现 抽象 请 求 处 理 方 法 handleRequest() ; 第 二 是 转发 请 求 ， 如 果 该 请 求 超出 了 当前 
处 理 者 类 的 权限 ， 可 以 将 该 请 求 转发 给 下 家 。 具 体 处 理 者 类 的 典型 代码 如 下 : 


class ConcreteHandler extends Handler { 
public void handleRequest(String request) { 
if (请 求 满足 条 件 ) { 


// 处 理 请 求 
} 
else { 

this,successor .handleRequest(request); // 转 发 请 求 
} 


} 

在 具体 处 理 类 中 通过 对 请 求 进行 判断 可 以 做 出 相应 的 处 理 。 

需要 注意 的 是 ， 职 责 链 模式 并 不 创建 职责 链 ， 职 责 链 的 创建 工作 必须 由 系统 的 其 他 部 分 来 完 
成 ， 一 般 是 在 使 用 该 职责 链 的 客户 端 中 创建 职责 链 。 职 责 链 模式 降低 了 请 求 的 发 送 端 和 接收 
端 之 间 的 耦合 ， 使 多 个 对 象 都 有 机 会 处 理 这 个 请 求 。 

思考 

如 何在 客户 端 创建 一 条 职责 链 ? 
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请 求 的 链 式 处 理 一 一 职责 链 模 式 (三 ) 
请 求 的 链 式 处 理 职责 链 模式 (三 ) 


16.3 完整 解决 方案 为 了 让 采购 单 的 审批 流程 更 加 灵活 ， 并 实现 采购 单 的 链 式 传递 和 处 理 ， 
Sunny 公 司 开 发 人 员 使 用 职责 链 模式 来 实现 采购 单 的 分 级 审批 ， 其 基本 结构 如 图 16-3 所 示 : 















PurchaseRequest 


- amount :double 

- number :int 

- purpose :String 

+ PurchaseRequest (double amount, 
int number, String purpose) 

+ setAmount (double amount) :void 

+ getAmount () :double 

+ setNumber (int number) :void 

+ getNumber () :int 

+ setPurpose (String purpose) i 

+ getPurpose () 





Approver 
{abstract} 


# successor :Approver 

# name : String 

+ Approver (String name) 

+ setSuccessor (Approver successor) -void 

+ processRequest (Purchase Request request) : void 
A 












Director Congress 














+ Director (String name) + Congress (String name) 
+ processRequest (PurchaseRequest request) :void + processRequest (PurchaseRequest re quest) : void 


+ VicePresident (String name) + President (String name) 
+ processRequest (PurchaseRequest request) : void | |+ processRequest (PurchaseRequest request) :void 


图 16-3 采购 单 分 级 审批 结构 图 


在 图 16-3 中 ， 抽 象 类 Approver 充 当 抽 象 处 理 者 (抽象 传递 者 ) ，Director、 VicePresident 、 
President 和 Congress 充 当 具 体 处 理 者 (具体 传递 者 ) ，PurchaseRequest 充 当 请 求 类 。 完 整 代码 
如 下 所 示 : 


// 采 购 单 : 请 求 类 

class PurchaseRequest { 
private double amount; // 采 购 金 额 
private int number; // 采 购 单 编号 
private String purpose; // 采 购 目的 


public PurchaseRequest(double amount, int number, String purpose 
this.amount = amount ， 
this,number = number ， 
this,purpose = purpose; 


} 


public void setAmount(double amount) { 
this.amount = amount ， 
} 


public double getAmount() { 
return this.amount,; 
} 
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public void setNumber(int number) { 
this.number = number ， 


} 


public int getNumber() { 
return this.number,; 
} 


public void setPurpose(String purpose) { 
this.purpose = purpose; 
} 


public String getPurpose() { 
return this.purpose; 
} 


} 


// 审 批 者 类 : 抽象 处 理 者 

abstract class Approver { 
protected Approver successor; // 定 义 后 继 对 象 
protected String name; // 审 批 者 姓名 


public Approver(String name) { 
this.name = name; 
} 


// 设 置 后 继 者 

public void setSuccessor(Approver successor) { 
this.successor = successor; 

} 


// 抽 象 请 求 处 理 方法 
public abstract void processRequest(PurchaseRequest request); 


} 


// 主 任 类 : 具体 处 理 者 
class Director extends Approver { 
public Director(String name) { 
super (name ); 
} 


// 具 体 请 求 处 理 方法 
public void processRequest(PurchaseRequest request) { 
if (request.getAmount() < 50000) { 
System.out.println(" 主 任 " + this.name + "审批 采购 单 :" + re 


} 
else { 

this.successor.processRequest(request); // 转 发 请 求 
} 


} 


// 副 董事 长 类 : 具体 处 理 者 
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class VicePresident extends Approver { 
public VicePresident(String name) { 
super (name ); 


} 


// 具 体 请 求 处 理 方法 
public void processRequest(PurchaseRequest request) { 
if (request.getAmount() < 100000) { 
System.out.println(" 副 董事 长 " + this.name + "审批 采购 单 :" 1 


} 
else { 

this.successor.processRequest(request); // 转 发 请 求 
} 


} 


// 和 董事 长 类 : 具体 处 理 者 
class President extends Approver { 
public President(String name) { 
super (name ); 


} 


// 具 体 请 求 处 理 方法 
public void processRequest(PurchaseRequest request) { 
if (request.getAmount() < 500000) { 
System.out .printLn(" 董 事 长 " + this.name + "审批 采购 单 :" + | 


} 
else { 

this.successor.processRequest(request); // 转 发 请 求 
} 


} 


// 和 董事 会 类 : 具体 处 理 者 
class Congress extends Approver { 
public Congress(String name) { 
super (name ); 


} 


// 具 体 请 求 处 理 方法 
public void processRequest(PurchaseRequest request) { 
System.out.println(" 召 开 董 事 会 审批 采购 单 : " + request.getNumber( 
} 
} 


编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String[] args) { 
Approver wjzhang,gyang,jguo,meeting; 
wjzhang = new Director(" 张 无 总" ) 
gyang = new VicePresident(" 杨 过 " ) ; 
jguo = new President(" 郭 靖 " ) ， 
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meeting = new Congress(" 董 事 会 " ) ; 


// 创 建 职责 链 
wjzhang.setSuccessor (gyang); 
gyang.setSuccessor(jguo); 
jguo.setSuccessor (meeting); 


// 创 建 采 购 单 
PurchaseRequest pr1 = new PurchaseRequest(45009,10001, "购买 倚 
wjzhang.processRequest(pr1); 


PurchaseRequest pr2 = new PurchaseRequest(690090,10002, "购买 《. 
wjzhang.processRequest (pr2); 


PurchaseRequest pr3 = new PurchaseRequest(160000,10003, "购买 ， 
wjzhang.processRequest (pr3); 


PurchaseRequest pr4 = new PurchaseRequest(800000,10004," 购 买书 
wjzhang.processRequest(pr4); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


主任 张无忌 审批 采购 单 : 10001， 金额 : 45000 .9 元， 采购 目的 : 购买 倚天 剑 。 

副 董 事 长 杨过 审批 采购 单 : 10002， 人 金额 : 60000 .0 元 ， 采 购 目 的 : 购买 《黄花 宝典 》 。 
董事 长 郭靖 审批 采购 单 : 100093， 人 金额 : 169000 .09 元， 采购 目的 : 购买 《金刚 经 》。 
召开 董事 会 审批 采购 单 : 10004， 人 金额 : 890000 .9 元 ， 采 购 目的 : 购买 桃花 岛 。 


如 果 需 要 在 系统 增加 一 个 新 的 具体 处 理 者 ， 如 增加 一 个 经 理 (Managen) 角 色 可 以 审批 5 万 元 至 8 
万 元 (不 包括 8 万 元 ) 的 采购 单 ， 需 要 编写 一 个 新 的 具体 处 理 者 类 Manager， 作 为 抽象 处 理 者 
类 Approver 的 子 类 ， 实 现在 Approver 类 中 定义 的 抽象 处 理 方法 ， 如 果 采 购 金 额 大 于 等 于 8 万 
元 ， 则 将 请 求 转发 给 下 家 ， 代 码 如 下 所 示 : 


// 经 理 类 : 具体 处 理 者 
class Manager extends Approver { 
public Manager(String name) { 
super (name ); 


} 


// 具 体 请 求 处 理 方法 
public void processRequest(PurchaseRequest request) { 
If (request.getAmount() < 80000) { 


System.out.println(" 经 理 " + this.name + "审批 采购 单 :" + re 
} 
else { 

this,successor .processRequest(request); // 转 发 请 求 
} 


} 


由 于 链 的 创建 过 程 由 客户 端 负责 ， 因 此 增加 新 的 具体 处 理 者 类 对 原 有 类 库 无 任何 影响 ， 无 须 
修改 已 有 类 的 源 代码 ， 符 合 “ 开 闭 原则 ”。 


257 


请 求 的 链 式 处 理 一 -职责 链 模式 (三 ) 





在 客户 端 代码 中 ， 如 果 要 将 新 的 具体 请 求 处 理 者 应 用 在 系统 中 ， 需 要 创建 新 的 具体 处 理 者 对 
象 ， 然 后 将 该 对 象 加 入 职责 链 中 。 如 在 客户 端 测试 代码 中 增加 如 下 代码 : 


Approver rhuang; 
rhuang = new Manager ("黄蓉")， 


将 建 链 代码 改 为 : 
// 创 | 建 职责 链 


wjzhang.setSuccessor(rhuang); // 将 2 莹 ”作为 “ 张 无 总 ”的 下 家 
rhuang.setSuccessor(gyang); /将 “杨过 ”作为 “黄蓉 ”的 下 家 
gyang.setSuccessor(jguo); 

jguo.setSuccessor(meeting); 


重新 编译 并 运行 程序 ， 输 出 结果 如 下 : 


主任 张无忌 审批 采购 单 : 10001， 人 金额 : 45000.0 元 ， 采 购 目的 : 购买 倚天 剑 。 经理 黄 营 审批 
采购 单 : 10002， 人 金额 : 60000.0 元 ， 采 购 目 的 : 购买 《 蒜 花 宝典 》。 董事 长 郭靖 审批 采购 
单 : 10003， 人 金额 : 160000.0 元 ， 采 购 目的 : 购买 《金刚 经 》。 召开 董事 会 审批 采购 单 : 


10004， 人 金额 : 800000.0 元 ， 采 购 目的 : 购买 桃花 岛 。 


如 果 将 审批 流程 由 “主任 --> 副 董事 长 --> 董 事 长 -> 董事 会 "调整 为 “主任 --> 董 事 长 -> 董事 
会 ”， 系 统 将 做 出 哪些 改动 ? 预测 修改 之 后 客户 端 代码 的 输出 结果 。 
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请 求 的 链 式 处 理 一 一 职责 链 模 式 (四 ) 
请 求 的 链 式 处 理 一 一 职责 链 模 式 (四 ) 


16.4 纯 与 不 纯 的 职责 链 模式 
职责 链 模 式 可 分 为 纯 的 职责 链 模式 和 不 纯 的 职责 链 模式 两 种 : 
(TD 纯 的 职责 链 模式 


一 个 纯 的 职责 链 模式 要 求 一 个 具体 处 理 者 对 象 只 能 在 两 个 行为 中 选择 一 个 : 要 么 承担 全 部 责 
任 ， 要 么 将 责任 推 给 下 家 ， 不 允许 出 现 某 一 个 具体 处 理 者 对 象 在 承担 了 一 部 分 或 全 部 责任 后 
又 将 责任 向 下 传递 的 情况 。 而 且 在 纯 的 职责 链 模式 中 ， 要 求 一 个 请 求 必 须 被 某 一 个 处 理 者 对 
象 所 接收 ， 不 能 出 现 某 个 请 求 未 被 任何 一 个 处 理 者 对 象 处 理 的 情况 。 在 前 面 的 采购 单 审 批 实 
例 中 应 用 的 是 纯 的 职责 链 模式 。 


(2) 不 纯 的 职责 链 模式 


在 一 个 不 纯 的 职责 链 模式 中 允许 某 个 请 求 被 一 个 具体 处 理 者 部 分 处 理 后 再 向 下 传递 ， 或 者 一 
个 具体 处 理 者 处 理 完 某 请 求 后 其 后 继 处 理 者 可 以 继续 处 理 该 请 求 ， 而 且 一 个 请 求 可 以 最 终 不 
被 任何 处 理 者 对 象 所 接收 。Java AWT 1.0 中 的 事件 处 理 模 型 应 用 的 是 不 纯 的 职责 链 模 式 ， 其 基 
本 原理 如 下 : 由 于 窗口 组 件 (如 按钮 、 文 本 框 等 ) 一 般 都 位 于 容器 组 件 中 ， 因 此 当 事 件 发 生 
在 某 一 个 组 件 上 时 ， 先 通过 组 件 对 象 的 handleEvent() 方 法 将 事件 传递 给 相应 的 事件 处 理 方法 ， 
该 事件 处 理 方 法 将 处 理 此 事件 ， 然 后 决定 是 否 将 该 事件 向 上 一 级 容器 组 件 传播 ; 上 级 容器 组 
件 在 接 到 事件 之 后 可 以 继续 处 理 此 事件 并 决定 是 否 继续 向 上 级 容器 组 件 传播 ， 如 此 反复 ， 直 
到 事件 到 达 顶 层 容器 组 件 为 止 ; 如 果 一 直 传 到 最 顶层 容器 仍 没 有 处 理 方法 ， 则 该 事件 不 子 处 
理 。 每 一 级 组 件 在 接收 到 事件 时 ， 都 可 以 处 理 此 事件 ， 而 不 论 此 事件 是 否 在 上 一 级 已 得 到 处 
理 ， 还 存在 事件 未 被 处 理 的 情况 。 显 然 ， 这 就 是 不 纯 的 职责 链 模式 ， 早 期 的 Java AWT 事 件 模 
型 (JDK 1.0 及 更 早 ) 中 的 这 种 事件 处 理 机 制 又 叫 事件 浮 升 Event Bubbling) 机 制 。 从 Java.1.1 以 
后 ，JDK 使 用 观察 者 模式 代替 职责 链 模 式 来 处 理事 件 。 目 前 ， 在 JavaScript 中 仍然 可 以 使 用 这 
种 事件 浮 升 机 制 来 进行 事件 处 理 。 


16.5 职责 链 模 式 总 结 

职责 链 模 式 通 过 建立 一 条 链 来 组 织 请 求 的 处 理 者 ， 请 求 将 沿 着 链 进 行 传递 ， 请 求 发 送 者 无 须 
知道 请 求 在 何 时 、 何 处 以 及 如 何 被 处 理 ， 实 现 了 请 求 发 送 者 与 处 理 者 的 解 碍 。 在 软件 开发 

中 ， 如 果 遇 到 有 多 个 对 象 可 以 处 理 同 一 请 求 时 可 以 应 用 职责 链 模式 ， 例 如 在 Web 应 用 开发 中 创 
建 一 个 过 滤器 (Filter) 链 来 对 请 求 数据 进行 过 滤 ， 在 工作 流 系统 中 实现 公文 的 分 级 审批 等 等 ， 使 
用 职责 链 模 式 可 以 较 好 地 解决 此 类 问题 。 

1. 主 要 优点 

职责 链 模 式 的 主要 优点 如 下 : 

(1) 职责 链 模式 使 得 一 个 对 象 无 须知 道 是 其 他 哪 一 个 对 象 处 理 其 请 求 ， 对 象 仅 需 知道 该 请 求 会 
被 处 理 即 可 ， 接 收 者 和 发 送 者 都 没有 对 方 的 明确 信息 ， 且 链 中 的 对 象 不 需要 知道 链 的 结构 ， 
由 客户 端 负责 链 的 创建 ， 降 低 了 系统 的 耦合 度 。 

(2) 请 求 处 理 对 象 仅 需 维 持 一 个 指向 其 后 继 者 的 引用 ， 而 不 需要 维持 它 对 所 有 的 候选 处 理 者 的 
引用 ， 可 简化 对 象 的 相互 连接 。 
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(3) 在 给 对 象 分 派 职 责 时 ， 职 责 链 可 以 给 我 们 更 多 的 灵活 性 ， 可 以 通过 在 运行 时 对 该 链 进行 动 
态 的 增加 或 修改 来 增加 或 改变 处 理 一 个 请 求 的 职责 。 


(4) 在 系统 中 增加 一 个 新 的 具体 请 求 处 理 者 时 无 须 修 改 原 有 系统 的 代码 ， 只 需要 在 客户 端 重新 
建 链 即 可 ， 从 这 一 点 来 看 是 符合 “ 开 闭 原则 ”的 。 


2. 主 要 缺点 
职责 链 模 式 的 主要 缺点 如 下 : 


(1) 由 于 一 个 请 求 没有 明确 的 接收 者 ， 那 么 就 不 能 保证 它 一 定 会 被 处 理 ， 该 请 求 可 能 一 直到 链 
的 末端 都 得 不 到 处 理 ; 一 个 请 求 也 可 能 因 职 责 链 没有 被 正确 配置 而 得 不 到 处 理 。 


(2) 对 于 比较 长 的 职责 链 ， 请 求 的 处 理 可 能 涉及 到 多 个 处 理 对 象 ， 系 统 性 能 将 受到 一 定 影响 ， 
而 且 在 进行 代码 调试 时 不 太 方便 。 


(3) 如 果 建 链 不 当 ， 可 能 会 造成 循环 调用 ， 将 导致 系 统 陷 入 死 循环 。 
3. 适 用 场景 
在 以 下 情况 下 可 以 考虑 使 用 职责 链 模 式 : 


(1) 有 多 个 对 象 可 以 处 理 同 一 个 请 求 ， 具 体 哪 个 对 象 处 理 该 请 求 待 运行 时 刻 再 确定 ， 客 户 端 只 
需 将 请 求 提交 到 链 上 ， 而 无 须 关心 请 求 的 处 理 对 象 是 谁 以 及 它 是 如 何 处 理 的 。 


(2) 在 不 明确 指定 接收 者 的 情况 下 ， 向 多 个 对 象 中 的 一 个 提交 一 个 请 求 。 


(3) 可 动态 指定 一 组 对 象 处 理 请 求 ， 客 户 端 可 以 动态 创建 职责 链 来 处 理 请 求 ， 还 可 以 改变 链 中 
处 理 者 之 间 的 先后 次 序 。 


练习 
Sunny 软 件 公司 的 OA 系统 需要 提供 一 个 假 条 审批 模块 : 如 果 员 工 请 假 天 数 小 于 3 天 ， 主 任 
可 以 审批 该 假 条 ; 如 果 员 工 请 假 天 数 大 于 等 于 3 天 ， 人 小 于 10 天 ， 经 理 可 以 审批 ; 如 果 员 工 


请 假 天 数 大 于 等 于 10 天 ， 小 于 30 天 ， 总 经 理 可 以 审批 ; 如 果 超 过 30 天 ， 总 经 理 也 不 能 审 
批 ， 提 示 相 应 的 拒绝 信息 。 试 用 职责 链 模式 设计 该 假 条 审批 模块 。 
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命令 模式 -Command Pattern 


命令 模式 -Command Pattern 【学习 难度 : 克 交 克 六 六 ， 使 用 频率 : 交友 交 太 交 】 
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请 求 发 送 者 与 接收 者 解 褐 一 一 命令 模式 (一 ) 
请 求 发 送 者 与 接收 者 解 辜 一 一 命令 模式 (一 ) 


装修 新 房 的 最 后 几 道 工序 之 一 是 安装 插座 和 开关 ， 通 过 开关 可 以 控制 一 些 电器 的 打开 和 关 
闭 ， 例 如 电灯 或 者 排 气 扇 。 在 购买 开关 时 ， 我 们 并 不 知道 它 将 来 到 底 用 于 控制 什么 电器 ， 也 
就 是 说 ， 开 关 与 电灯 、 排 气 扇 并 无 直接 关系 ， 一 个 开关 在 安装 之 后 可 能 用 来 控制 电灯 ， 也 可 
能 用 来 控制 排 气 遍 或 者 其 他 电器 设备 。 开 关 与 电器 之 间 通 过 电线 建立 连接 ， 如 果 开 关 打 开 ， 
则 电线 通电 ， 电 器 工作 ; 反之 ， 开 关 关 闭 ， 电 线 断 电 ， 电 器 停止 工作 。 相 同 的 开关 可 以 通过 
不 同 的 电线 来 控制 不 同 的 电器 ， 如 图 1 所 示 : 








接收 者 ( 电灯 ) 


( 冰 寺 ) 式 R 
| 


电线 





接收 者 ( 排 气 扇 ) 


图 1 开关 与 电灯 、 排 气 局 示意 图 


在 图 1 中 ， 我 们 可 以 将 开关 理解 成 一 个 请 求 的 发 送 者 ， 用 户 通过 它 来 发 送 一 个 “ 开 灯 ”请 求 ， 而 
电灯 是 “ 开 灯 ?请求 的 最 终 接 收 者 和 处 理 者 ， 在 图 中 ， 开 关 和 电灯 之 间 并 不 存在 直接 耦合 关系 ， 
它们 通过 电线 连接 在 一 起 ， 使 用 不 同 的 电线 可 以 连接 不 同 的 请 求 接收 者 ， 只 需 更 换 一 根 电 

线 ， 相 同 的 发 送 者 (开关 ) 即 可 对 应 不 同 的 接收 者 (电器 ) 。 

在 软件 开发 中 也 存在 很 多 与 开关 和 电器 类 似 的 请 求 发 送 者 和 接收 者 对 象 ， 例 如 一 个 按钮 ， 它 
可 能 是 一 个 “关闭 窗口 "请求 的 发 送 者 ， 而 按钮 点 击 事件 处 理 类 则 是 该 请 求 的 接收 者 。 为 了 降低 
系统 的 耦合 度 ， 将 请 求 的 发 送 者 和 接收 者 解 耦 ， 我 们 可 以 使 用 一 种 被 称 之 为 命令 模式 的 设计 
模式 来 设计 系统 ， 在 命令 模式 中 ， 发 送 者 与 接收 者 之 间 引 入 了 新 的 命令 对 象 《类 似 图 1 中 的 电 
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线 ) ， 将 发 送 者 的 请 求 封 装 在 命令 对 象 中 ， 再 通过 命令 对 象 来 调用 接收 者 的 方法 。 本 章 我 们 
将 学 习 用 干将 请 求 发 送 者 和 接收 者 解 看 的 命令 模式 。 


1 自 定义 功能 键 


Sunny 软 件 公司 开发 人 员 为 公司 内 部 OA 系统 开发 了 一 个 类 面 版 应 用 程序 ， 该 应 用 程序 为 用 户 
提供 了 一 系列 自 定义 功能 键 ， 用 户 可 以 通过 这 些 功能 键 来 实现 一 些 快捷 操作 。Sunny 软 件 公司 
开发 人 员 通 过 分 析 ， 发 现 不 同 的 用 户 可 能 会 有 不 同 的 使 用 习惯 ， 在 设置 功能 键 的 时 候 每 个 人 
都 有 自己 的 喜好 ， 例 如 有 的 人 喜欢 将 第 一 个 功能 键 设置 为 < 打开 帮助 文档 >»， 有 的 人 则 喜欢 将 该 
功能 键 设置 为 "最 小 化 至 托盘 "， 为 了 让 用 户 能 够 灵活 地 进行 功能 键 的 设置 ， 开 发 人 员 提供 了 一 

个 “功能 键 设置 "窗口 ， 该 窗口 界面 如 图 2 所 示 : 


功能 键 议 目 


功能 键 1: ”打开 帮助 文档 最 小 化 至 托盘 品 自 动 截屏 


功能 键 2: ”OO 打开 帮助 文档 最 小 化 至 托盘 O 〇 自动 截 屏 


功能 键 3: 打开 帮助 文档 最 小 化 至 托 竺 ”自动 截屏 
设置 医 到 到 


图 2“ 功 能 键 设置 ”界面 效果 图 





通过 如 图 2 所 示 界 面 ， 用 户 可 以 将 功 和 EE 键 和 相应 功 角 ta &， 还 可 以 根据 需要 来 修改 功能 
键 的 设置 ， 而 且 系 统 在 未 来 可 能 还 会 增加 一 些 新 的 功能 或 功能 键 。 


Sunny 软 件 公司 某 开 发 人 员 和 欲 使 用 如 下 代码 来 实现 功能 键 与 功能 处 理 类 之 间 的 调用 关系 : 


//FunctionButton : 功能 键 类 ， 请 求 发 送 者 
class FunctionButton { 
private HelpHandler help; //HelpHandler : 帮助 文档 处 理 类 ， 请 求 接收 者 


// 在 FunctionButton 的 onClick( ) 方 法 中 调用 HelpHandler 的 display() 方 法 
public void onClick() { 
help = new HelpHandler(); 
help.display(); // 显 示 帮 助 文档 


} 


在 上 述 代码 中 ， 功 能 键 类 FunctionButton 充 当 请 求 的 发 送 者 ， 帮 助 文档 处 理 类 HelpHandler 充 当 
请 求 的 接收 者 ， 在 发 送 者 FunctionButton 的 onClick() 方 法 中 将 调用 接收 者 HelpHandler 的 display() 
方法 。 显 然 ， 如 果 使 用 上 述 代码 ， 将 给 系统 带 来 如 下 几 个 问题 : 


(1) 由 于 请 求 发 送 者 和 请 求 接收 者 之 间 存 在 方法 的 直接 调用 ， 耦 合 度 很 高 ， 更 换 请 求 接收 者 必 
须 修改 发 送 者 的 源 代码 ， 如 果 需 要 将 请 求 接收 者 HelpHandler 改 为 WindowHanlder (窗口 处 理 
类 ) ， 则 需要 修改 FunctionButton 的 源 代码 ， 违 背 了 “ 开 闭 原则 ”。 


(2) FunctionButton 类 在 设计 和 实现 时 功能 已 被 固定 ， 如 果 增 加 一 个 新 的 请 求 接收 者 ， 如 果 不 修 
改 原 有 的 FunctionButton 类 ， 则 必须 增加 一 个 新 的 与 FunctionButton 功 能 类 似 的 类 ， 这 将 导致 系 
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统 中 类 的 个 数 急剧 增加 。 由 于 请 求 接 收 者 HelpHandler、WindowHanlder 等 类 之 问 可 能 不 存在 任 
何 关系 ， 它 们 没有 共同 的 抽象 层 ， 因 此 也 很 难 依据 “依赖 倒转 原则 ”来 设计 FunctionButton 。 


(3) 用 户 无 法 按照 自己 的 需要 来 设置 某 个 功能 键 的 功能 ， 一 个 功能 键 类 的 功能 一 旦 国定 ， 在 不 
修改 源 代码 的 情况 下 无 法 更 换 其 功能 ， 系 统 缺 乏 灵 活性 。 


不 难得 知 ， 所 有 这 些 问题 的 产生 都 是 因为 请 求 发 送 者 FunctionButton 类 和 请 求 接收 者 
HelpHandler、WindowHanlder 等 类 之 问 存 在 直接 耦合 关系 ， 如 何 降低 请 求 发 送 者 和 接收 者 之 问 
的 耦合 度 ， 让 相同 的 发 送 者 可 以 对 应 不 同 的 接收 者 ? 这 是 Sunny 软 件 公司 开发 人 员 在 设计 “ 功 
能 键 设置 > 模块 时 不 得 不 考虑 的 问题 。 命 令 模式 正 为 解决 这 类 问题 而 诞生 ， 此 时 ， 如 果 我 们 使 
用 命令 模式 ， 可 以 在 一 定 程 度 上 解决 上 述 问 题 ( 注 : 命令 模式 无 法 解决 类 的 个 数 增 加 的 问 
题 ) ， 下 面 就 让 我 们 正式 进入 命令 模式 的 学 习 ， 看 看 命令 模式 到 底 如何 实 现 请 求 发 送 者 和 接 
收 者 解 耦 。 


2 命令 模式 概述 


在 软件 开发 中 ， 我 们 经 常 需要 向 某 些 对 象 发 送 请 求 (调用 其 中 的 某 个 或 某 些 方法 ) ， 但 是 并 
不 知道 请 求 的 接收 者 是 谁 ， 也 不 知道 被 请 求 的 操作 是 哪个 ， 此 时 ， 我 们 特别 希望 能 够 以 一 种 
松 耦 合 的 方式 来 设计 软件 ， 使 得 请 求 发 送 者 与 请 求 接收 者 能 够 消除 彼此 之 间 的 看 合 ， 让 对 旬 
之 间 的 调用 关系 更 加 灵活 ， 可 以 灵活 地 指定 请 求 接收 者 以 及 被 请 求 的 操作 。 命 令 模式 为 此 类 
问题 提供 了 一 个 较为 完美 的 解决 方案 。 


命令 模式 可 以 将 请 求 发 送 者 和 接收 者 完全 解 耦 ， 发 送 者 与 接收 者 之 间 没 有 直接 引用 关系 ， 发 
送 请 求 的 对 象 只 需要 知道 如 何 发 送 请 求 ， 而 不 必 知 道 如 何 完成 请 求 。 
站 


命令 模式 定义 如 下 : 


5 


令 模 式 (Command Pattern) : 将 一 个 请 求 封装 为 一 个 对 象 ， 从 而 让 我 们 可 用 不 同 的 请 求 对 客户 
进行 参数 化 ; 对 请 求 排队 或 者 记录 请 求 日 志 ， 以 及 支持 可 撤销 的 操作 。 命 令 模 式 是 一 种 对 象 
为 型 模式 ， 其 别名 为 动作 (Actiom) 模 式 或 事务 (Transactiom) 模 式 。 


习 康 寺 


命令 模式 的 定义 比较 复杂 ， 提 到 了 很 多 术语 ， 例 如 “用 不 同 的 请 求 对 客户 进行 参数 化 "、“ 对 请 
求 排队 ”，“ 记 录 请 求 日 志 ”、“ 支 持 可 撤销 操作 ”等 ， 在 后 面 我 们 将 对 这 些 术语 进行 一 一 讲解 。 


命令 模式 的 核心 在 于 引入 了 命令 类 ， 通 过 命令 类 来 降低 发 送 者 和 接收 者 的 耦合 度 ， 请 求 发 送 
者 只 需 指 定 一 个 命令 对 象 ， 再 通过 命令 对 象 来 调用 请 求 接收 者 的 处 理 方 法 ， 其 结构 如 图 3 所 
示 : 
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图 3 命令 模式 结构 图 
在 命令 模式 结构 图 中 包含 如 下 几 个 角色 : 


e Command (抽象 命令 类 ) : 抽象 命令 类 一 般 是 一 个 抽象 类 或 接口 ， 在 其 中 声明 了 用 于 执行 
请 求 的 execute() 等 方法 ， 通 过 这 些 方法 可 以 调用 请 求 接收 者 的 相关 操作 。 


e@ ConcreteCommand (具体 命令 类 ) : 具体 命令 类 是 抽象 命令 类 的 子 类 ， 实 现 了 在 抽象 命令 类 
中 声明 的 方法 ， 它 对 应 具体 的 接收 者 对 象 ， 将 接收 者 对 象 的 动作 乡 定 其 中 。 在 实现 execute() 方 
法 时 ， 将 调用 接收 者 对 象 的 相关 操作 (Action) 。 


e Invoker (调用 者 ) : 调用 者 即 请 求 发 送 者 ， 它 通过 命令 对 象 来 执行 请 求 。 一 个 调用 者 并 不 
需要 在 设计 时 确定 其 接收 者 ， 因 此 它 只 与 抽象 命 令 类 之 间 存 在 关联 关系 。 在 程序 运行 时 可 以 
将 一 个 具体 命令 对 象 注入 其 中 ， 再 调用 具体 命令 对 象 的 execute() 方 法 ， 从 而 实现 间接 调用 请 求 
接收 者 的 相关 操作 。 


e@ Receiver (接收 者 ) : 接收 者 执行 与 请 求 相 关 的 操作 ， 它 具体 实现 对 请 求 的 业务 处 理 。 


命令 模式 的 本 质 是 对 请 求 进行 封 装 ， 一 个 请 求 对 应 于 一 个 命令 ， 将 发 出 命令 的 责任 和 执行 命 
令 的 责任 分 割 开 。 每 一 个 命令 都 是 一 个 操作 : 请 求 的 一 方 发 出 请 求 要 求 执行 一 个 操作 ; 接收 
的 一 方 收 到 请 求 ， 并 执行 相应 的 操作 。 命 令 模式 允许 请 求 的 一 方 和 接收 的 一 方 独立 开 来 ， 使 
得 请 求 的 一 方 不 必 有 知道 接收 请 求 的 一 方 的 接口 ， 更 不 必 有 知道 请 求 如 何 被 接收 、 操 作 是 否 被 执 
行 、 何 时 被 执行 ， 以 及 是 怎么 被 执行 的 。 
命令 模式 的 关键 在 于 引入 了 抽象 命令 类 ， 请 求 发 送 者 针对 抽象 命令 类 编程 ， 只 有 实现 了 抽象 
命令 类 的 具体 命令 才 与 请 求 接收 者 相关 联 。 在 最 简单 的 抽象 命令 类 中 只 包含 了 一 个 抽象 的 
execute() 方 法 ， 每 个 具体 命令 类 将 一 个 Receiver 类 型 的 对 象 作为 一 个 实例 变量 进行 存储 ， 从 而 
具体 指定 一 个 请 求 的 接收 者 ， 不 同 的 具体 命令 类 提供 了 execute() 方 法 的 不 同 实现 ， 并 调用 不 同 
接收 者 的 请 求 处 理 方法 。 典型 的 抽象 命令 类 代码 如 下 所 示 : 
abstract class Command { 

public abstract void execute(); 
} 


对 于 请 求 发 送 者 即 调用 者 而 言 ， 将 针对 抽象 命令 类 进行 编程 ， 可 以 通过 构造 注入 或 者 设 值 注 
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入 的 方式 在 运行 时 传 入 具体 命令 类 对 象 ， 并 在 业务 方法 中 调用 命令 对 象 的 execute() 方 法 ， 其 典 
型 代码 如 下 所 示 : 


class Invoker { 
private Command command ; 


// 构 造 注入 

public Invoker(Command command ) { 
this.command = command ， 

} 


// 设 值 注入 

public void setCommand(Command command) 区 
this.command = command; 

} 


// 业 务 方法 ， 用 于 调用 命令 类 的 execute( ) 方 法 
public void call() { 

command .execute( ); 
} 


} 


具体 命令 类 继承 了 抽象 命令 类 ， 它 与 请 求 接收 者 相关 联 ， 实 现 了 在 抽象 命令 类 中 声明 的 
execute() 方 法 ， 并 在 实现 时 调用 接收 者 的 请 求 响 应 方法 action()， 其 典型 代码 如 下 所 示 : 


class ConcreteCommand extends Command { 
private Receiver receiver; // 维 持 一 个 对 请 求 接收 者 对 象 的 引用 


public void execute() { 
receiver.action(); // 调 用 请 求 接 收 者 的 业务 处 理 方法 action() 
} 


} 


请 求 接收 者 Receiver 类 具体 实现 对 请 求 的 业务 处 理 ， 它 提供 了 action0 方 法 ， 用 于 执行 与 请 求 相 


class Receiver { 
public void action() { 
// 具 体操 作 
} 


} 


一 个 请 求 发 送 者 能 否 对 应 多 个 请 求 接收 者 ? 如 何 实现 ? 
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请 求 发 送 者 与 接收 者 解 耦 一 命令 模式 (二 ) 
请 求 发 送 者 与 接收 者 解 看 一 一 命令 模式 (二) 


3 完整 解决 方案 


为 了 降低 功能 键 与 功能 处 理 类 之 间 的 耦合 度 ， 让 用 户 可 以 自 定 义 每 一 个 功能 键 的 功能 ，Sunny 
软件 公司 开发 人 员 使 用 命令 模式 来 设计 “ 自 定义 功能 键 " 模 块 ， 其 核心 结构 如 图 4 所 示 : 





whObjminimize(); | | hhobjdisplay(} | 


图 4 自 定义 功能 键 核心 结构 图 


在 图 4 中 ，FBSettingWindow 是 “功能 键 设置 "界面 类 ，FunctionButton 充 当 请 求 调用 者 ， 
Command 充 当 抽 和 象 命令 类 ，MinimizeCommand 和 HelpCommand 充 当 具 体 命令 类 ， 
WindowHanlder 和 HelpHandler 充 当 请 求 接收 者 。 完 整 代码 如 下 所 示 : 


import java,util.*， 


// 功 能 键 设置 窗口 类 
class FBSettingwindow { 
private String title; // 窗 口 标题 
// 定 义 一 个 ArrayList 来 存储 所 有 功能 键 
private ArrayList<FunctionButton> functionButtons = new ArrayLis. 


public FBSettingwindow(String title) { 
this.title = titile; 
} 


public void setTitle(String title) { 
this.title = titile; 
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} 


public String getTitle() { 
return this.title,; 
} 


public void addFunctionButton(FunctionButton fb) { 
functionButtons.add(fb); 
} 


public void removeFunctionButton(FunctionButton fb) { 
functionButtons.remove(fb); 


} 

// 显 示 窗 口 及 功能 键 

public void display() { 
System.out.println(" 显 示 窗 口 :" + this.title)，; 
System.out.println(" 显 示 功 能 键 : ")， 
for (Object obj : functionButtons) { 

System.out.println(((FunctionButton)obj).getName()); 

} 
System.out.print]n( -= "); 

} 


} 


// 功 能 键 类 : 请 求 发 送 者 
class FunctionButton { 
private String name; // 功 能 键 名 称 
private Command command; // 维 持 一 个 抽象 命令 对 象 的 引用 


public FunctionButton(String name) { 
this.name = name; 
} 


public String getName() { 
return this.name,; 
} 


// 为 功能 键 注入 命令 

public void setCommand(Command command) 区 
this.command = command; 

} 


// 发 送 请 求 的 方法 

public void onClick() { 
System.out.print(" 点 击 功 能 键 : ")， 
command ,execute( ); 


} 


// 抽 象 命令 类 
abstract class Command { 
public abstract void execute(); 
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} 


// 帮 助 命令 类 : 具体 命令 类 
class HelpCommand extends Command { 
private HelpHandler hh0bj; // 维 持 对 请 求 接收 者 的 引用 


public HelpCommand() { 
hhobj = new HelpHandler( ); 
} 


// 命 令 执 行 方法 ， 将 调用 请 求 接收 者 的 业务 方法 
public void execute() { 

hhobj .display(); 
} 


} 


// 最 小 化 命令 类 : 具体 命令 类 
class MinimizeCommand extends Command { 
private WindowHanlder wh0bj; // 维 持 对 请 求 接收 者 的 引用 


public MinimizeCommand() { 
whobj = new WindowHanlder(); 


} 


// 命 令 执行 方法 ， 将 调用 请 求 接收 者 的 业务 方法 
public void execute() { 
whobj .minimize(); 
} 


} 


// 窗 口 处 理 类 : 请 求 接收 者 
class WindowHanlder { 
public void minimize() { 
System.out .println(" 将 窗口 最 小 化 至 托盘 1")) 
} 


} 


// 帮 助 文档 处 理 类 : 请 求 接收 者 
class HelpHandler { 
public void display() { 
System.out.println(" 显 示 帮 助 文档 ! ")， 
} 


} 


为 了 提高 系统 的 灵活 性 和 可 扩展 性 ， 我 们 将 具体 命令 类 的 类 名 存储 在 配置 文件 中 ， 并 通过 工 


具 类 XMLUtil 来 读 取 配 置 文件 并 反射 生成 对 象 ，XMLUtil 类 的 代码 如 下 所 示 : 


Import javax.xml.parsers.* 
import org.w3c.dom.*,; 

import org.xml.sax.SAXException; 
import java.io,.*,; 


public class XMLUtil { 
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// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 ， 可 以 通过 参数 的 不 同 
public static Object getBean(int i) { 
try { 
// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory.newDocumentBuilder( ); 
Document doc; 
doc = builder.parse(new File("config.xml")); 


// 获 取 和 包含 类 名 的 文本 节点 
NodeList nl = doc.getElementsByTagName("className"); 
Node classNode = null; 
if (0 == i) { 
classNode = nl.item(0).getFirstcChild(); 


} 
else { 

classNode = nl.item(1).getFirstcChild(); 
} 


String cName = classNode.getNodeVvalue(); 


// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c = Class.forName(cNanme); 
Object obj = c.newInstance!(); 
return obj; 


catch(Exception e){ 
e.printStackTrace( ) ; 
return null; 


} 
配置 文件 config.xml 中 存储 了 具体 建造 者 类 的 类 名 ， 代 码 如 下 所 示 : 


<?xml1 version="1.0"?> 
<config> 
<className>HelpCommand</className> 
<className>MinimizeCommand</className> 
</config> 
编写 如 下 客户 端 测试 代码 : 
[java] view plain copy 
class Client { 
public static void main(String args[]) { 
FBSettingwindow fbsw = new FBSettingwWindow(" 功 能 键 设置 ")， 


FunctionButton fb1,fb2; 
fb1 = new FunctionButton(" 功 能 键 1" ) ; 
fb2 = new FunctionButton(" 功 能 键 1" ) ; 


Command command1, command2 
// 通 过 读 取 配置 文件 和 反射 生成 具体 命令 对 象 
command1 = (Command)XMLUtiI .getBean(0) ; 
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command2 = (Command)XMLUtil.getBean(1); 


// 将 命令 对 象 注入 功能 键 
fb1.setCommand(command1) ， 
fb2.setCommand(command2); 


fbsw.addFunctionButton(fb1); 
fbsw.addFunctionButton(fb2); 
fbsw.display( ); 


// 调 用 功能 键 的 业务 方法 
fbi.oncClick(); 
fb2.oncClick( ); 


示 窗 口 : 功能 键 设置 
示 功 能 键 : 
能 键 1 


点 击 功能 键 : 显示 帮助 文档 ! 
点 击 功 能 键 : 将 窗口 最 小 化 至 托盘 |! 


如 果 需 要 修改 功能 键 的 功能 ， 例 如 茶 个 功能 键 可 以 实现 “自动 截屏 ”只 需要 对 应 增加 一 个 新 的 
具体 命令 类 ， 在 该 命令 类 与 屏幕 处 理 者 (ScreenHandlen) 之 问 创建 一 个 关联 关系 ， 然 后 将 该 具体 
命令 类 的 对 象 通过 配置 文件 注入 到 某 个 功能 键 即 可 ， 原 有 代码 无 须 修 改 ， 符 合 “ 开 闭 原则 ”。 在 
此 过 程 中 ， 每 一 个 具体 命令 类 对 应 一 个 请 求 的 处 理 者 (接收 者 ) ， 通 过 向 请 求 发 送 者 注入 不 
同 的 具体 命令 对 象 可 以 使 得 相同 的 发 送 者 对 应 不 同 的 接收 者 ， 从 而 实现 “将 一 个 请 求 封 装 为 一 
个 对 象 ， 用 不 同 的 请 求 对 客户 进行 参数 化 "， 客 户 端 只 需要 将 具体 命令 对 象 作为 参数 注入 请 求 
发 送 者 ， 无 须 直接 操作 请 求 的 接收 者 。 
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请 求 发 送 者 与 接收 者 解 契 一 命令 模式 (三 ) 
请 求 发 送 者 与 接收 者 解 丰 一 命令 模式 (三 ) 


4 命令 队列 的 实现 
有 时 候 我 们 需要 将 多 个 请 求 排队 ， 当 一 个 请 求 发 送 者 发 送 一 个 请 求 时 ， 将 不 止 一 个 请 求 接收 


者 产生 响应 ， 这 些 请 求 接收 者 将 逐个 执行 业务 方法 ， 完 成 对 请 求 的 处 理 。 此 时 ， 我 们 可 以 通 
过 命令 队列 来 实现 。 


=) 


命令 队列 的 实现 方法 有 多 种 形式 ， 其 中 最 常用 、 灵 活性 最 好 的 一 种 方式 是 增加 一 个 
CommandQueue 类 ， 由 该 类 来 负责 存储 多 个 命令 对 象 ， 而 不 同 的 命令 对 象 可 以 对 应 不 同 的 请 求 
接收 者 ，CommandQueue 类 的 典 型 代码 如 下 所 趣 示 : 


import java.util.*,; 


class CommandQueue { 
// 定 义 一 个 ArrayList 来 存储 命令 队列 
private ArrayList<Command> commands = new ArrayList<Command>(); 


public void addCommand(Command command) 区 
commands .add(command ) ; 
} 


public void removeCommand(Command command) { 
commands.remove(command); 
} 


// 循 环 调用 每 一 个 命令 对 象 的 execute( ) 方 法 
public void execute( ) { 
for (Object command : commands) { 
((Command )command ) .execute( ); 
} 


} 


在 增加 了 命令 队列 类 CommandQueue 以 后 ， 请 求 发 送 者 类 Invoker 将 针对 CommandQueue 编 程 ， 
代码 修改 如 下 : 


class Invoker { 
private CommandQueue commandQueue; // 维 持 一 个 CommandQueue 对 象 的 引用 


// 构 造 注入 

public Invoker(CommandQueue commandQueue) { 
this. commandQueue = commandQueue; 

} 


// 设 值 注入 
public void setCommandQueue(CommandQueue commandQueue) { 
this.commandQueue = commandQueue; 
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命令 模式 (三 ) 





} 


// 调 用 CommandQueue 类 的 execute() 方 法 
public void call() { 

commandQueue .execute( ); 
} 


} 


命令 队列 与 我 们 常 说 的 “ 批 处 理 ? 有 点 类 似 。 批 处 理 ， 顾 名 思 义 ， 可 以 对 一 组 对 象 (命令 ) 进行 
批量 处 理 ， 当 一 个 发 送 者 发 送 请 求 后 ， 将 有 一 系列 接收 者 对 请 求 作出 响应 ， 命 令 队 列 可 以 用 
于 设计 批 处 理应 用 程序 ， 如 果 请 求 接收 者 的 接收 次 序 没有 严格 的 先后 次 序 ， 我 们 还 可 以 使 用 
多 线程 技术 来 并 发 调用 命令 对 象 的 execute() 方 法 ， 从 而 提高 程序 的 执行 效率 。 
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=) 


求 发 送 者 与 接收 者 解 耦 _ ”命令 模式 (四) 
求 发 送 者 与 接收 者 解 耦 _ ”命令 模式 (四) 


5 撤销 操作 的 实现 


在 命令 模式 中 ， 我 们 可 以 通过 调用 一 个 命令 对 象 的 execute() 方 法 来 实现 对 请 求 的 处 理 ， 如 果 需 
要 撤销 (Undo) 请 求 ， 可 通过 在 命令 类 中 增加 一 个 逆向 操作 来 实现 。 


扩展 

除了 通过 一 个 北向 操作 来 实现 撤销 (Undo) 外 ， 还 可 以 通过 保存 对 象 的 历史 状态 来 实现 撤销 ， 后 
者 可 使 用 备忘录 模式 (Memento Pattern) 来 实现 。 

下 面 通过 一 个 简单 的 实例 来 学 习 如 何 使 用 命令 模式 实现 撤销 操作 : 

Sunny 软 件 公司 和 谷 开 发 一 个 简易 计算 器 ， 该 计算 器 可 以 实现 简单 的 数学 运算 ， 还 可 以 对 运算 

施 撤销 操作 。 


Sunny 软 件 公司 开发 人 员 使 用 命令 模式 设计 了 如 图 5 所 示 结 构图 ， 其 中 计算 器 界面 类 
CalculatorForm 充 当 请 求 发 送 者 ， 实 现 了 数据 求 和 功能 的 加 法 类 Adder 充 当 请 0 ， 界面 类 
可 间接 调用 加 法 类 中 的 add0) 方 法 实现 加 法 运算 ， 并 且 提 供 了 可 撤销 加 法 运算 的 undo() 方 法 。 


















AbstractCommand 
{abstract} 


CalculatorForm 
- command : AbstractCommand 
+ setCommand (AbstractCommand command) : void 
+ compute (int value) : void 
+ undo () : void 














+ execute (int value) : int 
+ undo () :int 









































AddCommand 
- adder : Adder 
num :int =0 | lu 
+ execute (int value) : int 


+ undo () :int 





图 5 简易 计算 器 结构 图 
本 实例 完整 代码 如 下 所 示 : 


// 加 法 类 : 请 求 接收 者 
class Adder { 
private int num=0; // 定 义 初 始 值 为 0 


// 加 法 操作 ， 每 次 将 传 入 的 值 与 hum 作 加 法 运算 ， 再 将 结果 返回 
public int add(int value) { 

num += value; 

return num,; 
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} 


// 抽 象 命令 类 

abstract class AbstractCommand { 
public abstract int execute(int value); // 声 明 命令 执行 方法 execute( ) 
public abstract int undo(); // 声 明 撤 销 方法 undo( ) 


} 


// 具 体 命 令 类 

class ConcreteCommand extends AbstractCommand { 
private Adder adder = new Adder(); 
private int value; 


// 实 现 抽象 命令 类 中 声明 的 execute( ) 方 法 ， 调 用 加 法 类 的 加 法 操作 
public int execute(int value) { 
this.value=value; 
return adder .add(value); 


} 


/7/ 实 现 抽象 命令 类 中 声明 的 undo( ) 方 法 ， 通 过 加 一 个 相反 数 来 实现 加 法 的 逆向 操作 
public int undo() { 

return adder.add(-value); 
} 


} 


// 计 算 器 界面 类 : 请 求 发 送 者 
class CalculatorForm { 
private AbstractCommand command; 


public void setCommand(AbstractCommand command) { 
this.command = command; 


} 


// 调 用 命令 对 象 的 execute( 1) 方法 执行 运算 
public void compute(int value) { 

int i = command. execute(value); 

System.out .printlLn(" 执 行 运 算 ， 运 算 结 果 为 :" + i); 
} 


// 调 用 命令 对 象 的 undo( ) 方 法 执行 撤销 

public void undo() { 
int i = command.undo(); 
System.out.println(" 执 行 撤销 ,运算 结果 为 :" + 工 ); 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
CalculatorForm form = new CalculatorForm(); 
AbstractCommand command; 
command = new Concretecommand ( ) ， 
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form.setCommand(command) ; // 向 发 送 者 注入 命令 对 象 


form.compute(10); 
form.compute(5); 
form.compute(10); 
form.undo( ) ; 


} 
} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 
执行 运算 ， 运 算 结 果 为 : 10 
执行 运算 ， 运 算 结 果 为 : 15 
执行 运算 ， 运 算 结果 为 : 25 
执行 撤销 ， 运 算 结果 为 : 15 


思考 
如 果 连 续 调 用 “form.undo()” 两 次 ， 预 测 客 户 端 代码 的 输出 结果 。 
需要 注意 的 是 在 本 实例 中 只 能 实现 一 步 撤销 操作 ， 因 为 没有 保存 命令 对 象 的 历史 状态 ， 
可 以 通过 引入 一 个 命令 集合 或 其 他 方式 来 存储 每 一 次 操作 时 命令 的 状态 ， 从 而 实现 多 次 
撤销 操作 。 除 了 Undo 操 作 外 ， 还 可 以 采用 类 似 的 方式 实现 恢复 (Redo) 操 作 ， 即 恢复 所 撤 
销 的 操作 (或 称 为 二 次 撤销 ) 。 

练习 


修改 简易 计算 器 源 代码 ， 使 之 能 够 实现 多 次 撤销 (Undo) 和 恢复 (Redo)。 
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请 求 发 送 者 与 接收 者 解 看 一 命令 模式 (五) 
请 求 发 送 者 与 接收 者 解 看 一 命令 模式 (五 ) 


6 请 求 日 志 


请 求 日 志 就 是 将 请 求 的 历史 记录 保存 下 来 ， 通 常 以 日 志文 件 (Log File) 的 形式 永久 存储 在 计算 
机 中 。 很 多 系统 都 提供 了 日 志文 件 ， 例 如 Windows 日 志文 件 、Oracle 日 志文 件 等 ， 日 志文 件 可 
以 记录 用 户 对 系统 的 一 些 操 作 (例如 对 数据 的 更 改 ) 。 请 求 日 志文 件 可 以 实现 很 多 功能 ， 常 
用 功能 如 下 : 


(1) “天 有 不 测 风 云 "， 一 旦 系统 发 生 故 障 ， 日 志文 件 可 以 为 系统 提供 一 种 恢复 机 制 ， 在 请 求 日 
志文 件 中 可 以 记录 用 户 对 系统 的 每 一 步 操作 ， 从 而 让 系统 能 够 顺利 恢复 到 某 一 个 特定 的 状 

态 ; 

(2) 请 求 日 志 也 可 以 用 于 实现 批 处 理 ， 在 一 个 请 求 日 志文 件 中 可 以 存储 一 系列 命令 对 象 ， 例 如 
一 个 命令 队列 ; 


(3) 可 以 将 命令 队列 中 的 所 有 命令 对 象 都 存储 在 一 个 日 志文 件 中 ， 每 执行 一 个 命令 则 从 日 志 冯 

件 中 删除 一 个 对 应 的 命令 对 象 ， 防 止 因 为 断 电 或 者 系统 重启 等 原因 造成 请 求 丢 失 ， 而 且 可 以 

避免 重新 发 送 全 部 请 求 时 造成 菜 些 命令 的 重复 执行 ， 只 需 读 取 请 求 日 志文 件 ， 再 继续 执行 文 

件 中 剩余 的 命令 即 可 。 

在 实现 请 求 日 志 时 ， 我 们 可 以 将 命令 对 象 通过 序列 化 写 到 日 志文 件 中 ， 此 时 命令 类 必须 实现 

Java.io.Serializable 接 口 。 下 面 我 们 通过 一 个 简单 实例 来 说 明日 志文 件 的 用 途 以 及 如 何 实现 请 求 


日 志 : 


Sunny 软 件 公司 开发 了 一 个 网 站 配置 文件 管理 工具 ， 可 以 通过 一 个 可 视 化 界面 对 网 站 配置 文件 
进行 增删 改 等 操作 ， 该 工具 使 用 命令 模式 进行 设计 ， 结 构 如 图 6 所 示 : 
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i 
= 


config.log 
图 6 网 站 配置 文件 管理 工具 结构 图 


现在 Sunny 软 件 公司 开发 人 员 和 希望 将 对 配置 文件 的 操作 请 求 记录 在 日 志文 件 中 ， 如 果 网 站 重新 
部 署 ， 只 需要 执行 保存 在 日 志文 件 中 的 命令 对 象 即 可 修改 配置 文件 。 


本 实例 完整 代码 如 下 所 示 : 


import java.io.*; 
import java.util.*,; 


// 抽 象 命令 类 ， 由 于 需要 将 命令 对 象 写 入 文件 ， 因 此 它 实现 了 Serializab1le 接 口 
abstract class Command implements Serializable { 

protected String name; // 命 令 名 称 

protected String args; // 命 令 参数 

protected Configoperator configOperator; // 维 持 对 接收 者 对 象 的 引用 


public Command(String name) { 
this.name = name; 


} 


public String getName() { 
return this.name,; 


} 


public void setName(String name) { 
this.name = name; 


} 
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public void setConfigOperator(ConfigOperator configOperator) { 
this.configOperator = configoperator 


} 


// 声 明 两 个 抽象 的 执行 方法 execute( ) 
public abstract void execute(String args) 
public abstract void execute( ) 


} 


// 增 加 命令 类 : 具体 命令 
class InsertCommand extends Command { 
public InsertCommand(String name) { 
super (name ); 


} 


public void execute(String args) { 
this.args = args; 
configOperator.insert(args); 


} 


public void execute() { 
configOperator.insert(this.args); 
} 


} 


// 修 改 命令 类 : 具体 命令 
class ModifyCommand extends Command { 
public ModifyCommand(String name) { 
super (name ); 


} 


public void execute(String args) { 
this.args = args,; 
configoperator .modify(args); 


} 


public void execute() { 
configOperator.modify(this.args); 
} 


} 
// 省 咯 了 删除 命令 类 DeleteCcommand 
// 配 置 文件 操作 类 : 请 求 接收 者 。 由 于 Configoperator 类 的 对 象 是 Command 的 成 员 对 象 ，， 


class Configoperator implements Serializable { 
public void insert(String args) { 


System.out.println(" 增 加 新 节点 :" + args); 
} 
public void modify(String args) { 
System,out .println(" 修 改 节点 :" + args)， 
} 
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public void delete(String args) { 
System.out.println(" 删 除 节点 :" + args); 
} 
} 


// 配 置 文件 设置 窗口 类 : 请 求 发 送 者 

class ConfigSettingwindow { 
// 定 义 一 个 集合 来 存储 每 一 次 操作 时 的 命令 对 象 
private ArrayList<Command> commands = new ArrayList<Command>(); 
private Command command ; 


// 注 入 具体 命令 对 象 
public void setCommand(Command command ) { 
this,command = command; 


} 


// 执 行 配置 文件 修改 命令 ， 同 时 将 命令 对 象 添加 到 命令 集合 中 
public void call(String args) { 

command .execute(args); 

commands .add(command); 


} 


// 记 录 请 求 日 志 ， 生 成 日 志文 件 ， 将 命令 集合 写 入 日 志文 件 
public void save() { 

FileUtil.writeCommands (commands ) ; 
} 


// 从 日 志文 件 中 提取 命令 集合 ， 并 循环 调用 每 一 个 命令 对 象 的 execute( ) 方 法 来 实现 配 
public void recover() { 

ArrayList list; 

list = FileUtil.readCommands(); 


for (Object obj : list) { 
((Command )obj) ,execute() ; 


} 
} 


// 工 具 类 : 文件 操作 类 
class FileUtil { 
// 将 命令 集合 写 入 日 志文 件 
public static void writeCommands(ArrayList commands) { 
try { 
FileOutputStream file = new FileOutputStream("config.1og 
// 创 建 对 象 输出 流 用 于 将 对 象 写 入 到 文件 中 
ObjectOutputStream objout = new ObjectOutputStream(new BI 
// 将 对 象 写 入 文件 
objout ,write0bject(commands ) ， 
objout.close( ); 


catch(Exception e) { 
System.out ,printLn(" 命 令 保存 失败 ! ")， 
e.printSstackTrace(); 
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// 从 日 志文 件 中 提取 命令 集合 
public static ArrayList readCommands() { 


try { 
FileInputStream file = new FileInputSstream("config.1o0g") 


// 创 建 对 象 输入 流 用 于 从 文件 中 读 取 对 象 
ObjectInputStream objin = new ObjectIinputStream(new Buff 


// 将 文件 中 的 对 象 读 出 并 转换 为 ArrayList 类 型 

ArrayList commands = (ArrayList)objin.readobject() ， 

objin,close() 

return commands,; 

} 

catch(Exception e) { 

System.out .println(" 命 令 读 取 失败 | ")， 
e,printStackTrace( ); 
return null; 


编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
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ConfigSettingwindow csw = new ConfigSettingwindow(); // 定 义 请 
Command command; // 定 义 命 令 对 象 
Configoperator co = new Configoperator()， // 定 义 请 求 接收 者 


// 四 次 对 配置 文件 的 更 改 

command = new InsertCommand(" 增 加 ") ; 
command ,setConfigoperator(co) ; 
csw.setCommand(command ) ; 
CSw,CalL1(" 网 站 首页 ") ， 


command = new InsertCommand(" 增 加 ") ; 
command ,setConfigoperator(co) ; 
cSsw.SetCommand(command ); 

CSw, Cal1( "端口 号" ) ; 


command = new ModifyCommand(" 修 改 " ) ; 
command ,setConfigoperator(co) ; 
csw,SetCcommand(command ) ; 
CSw,Cal1(" 网 站 首页 ") ， 


command = new ModifyCommand(" 修 改 " ) ; 
command ,setConfigoperator(co) ; 
csw.setCommand(command ) ; 


号 


CSW.call(" 端 口号 ")， 


System.out.println(---------------------------- > 
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System,out,.println(" 保 存 配置 " ) ; 
csw.save( ); 


System,.out.println("------------------- 


System,out,printlLn(" 恢 复 配置 " ) ; 


System.out.println("------------------- 


csw.recover(); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


增加 新 节点 : 网 站 首页 
增加 新 节点 : 端口 号 
修改 节点 : 网 站 首页 
修改 节点 : 端口 号 


增加 新 节点 : 网 站 首页 
增加 新 节点 : 端口 号 
修改 节点 : 网 站 首页 
修改 节点 : 端口 号 
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请 求 发 送 者 与 接收 者 解 不 一 命令 模式 (六 ) 
请 求 发 送 者 与 接收 者 解 不 一 命令 模式 (六 ) 


宏 命令 (Macro Command) 又 称 为 组 合 命令 ， 它 是 组 合 模式 和 命 命令 模式 联 用 的 产物 。 宏 命令 是 一 
个 具体 命令 类 ， 它 拥有 一 个 集合 属性 ， 在 该 集合 中 包含 了 对 其 他 命令 对 象 的 引用 。 通 常 宏 命 
令 不 直接 与 请 求 接收 者 交互 ， 而 是 通过 它 的 成 员 来 调用 接收 者 的 方法 。 当 调 用 宏 命令 的 
J 将 递归 调用 它 所 包含 的 每 个 成 员 命 令 的 execute() 方 法 ， 一 个 宏 命令 的 成 员 可 
以 是 简单 命令 ， 还 可 以 继续 是 宏 命令 。 执 行 一 个 宏 命令 将 触发 多 个 具体 命 令 的 执行 ， 从 而 实 
7 ， 其 结构 如 图 7 所 示 : 











Command 








+ addCommand (Command command) 

+ removeCommand (Command command) 
+ getCommand (int i) 

+ execute () 




















' 
- commands : ArrayList<Command> 


+ addCommand (Command command) 
+ removeCommand (Command command) 
+ getCommand (inti) 

+、execute () 


for(Object command:commands) { 
((Object}command).execute(); 
} 


命令 模式 是 一 种 使 用 频率 非常 高 的 设计 模式 ， oo ， 请 求 发 送 
者 通过 命令 对 象 来 间接 引用 请 求 接 收 者 ， 使 得 系统 具有 更 好 的 灵活 性 和 可 扩展 性 。 在 基于 GUI 
的 软件 开发 ， 无 论 是 在 电脑 桌面 应 用 还 .是 在 移动 应 用 中 ， 命 令 模式 都 得 到 了 广泛 的 应 用 。 


ConcreteCommandA 


ConcreteCommandB 











1. 主要 优点 
命令 模式 的 主要 优点 如 下 : 
(1) 降低 系统 的 耦合 度 。 由 于 请 求 者 与 接收 者 之 间 不 存在 直接 引用 ， 因 此 请 求 者 与 接收 者 之 间 
实现 完全 解 耦 ， 相 同 的 请 求 者 可 以 对 应 不 同 的 接收 者 ， 同 样 ， 相 同 的 接收 者 也 可 以 供 不 同 的 
请 求 者 使 用 ， 两 者 之 间 具 有 良好 的 独立 性 。 


(2) 新 的 命令 可 以 很 容易 地 加 入 到 系统 中 。 由 于 增加 新 的 具体 命令 类 不 会 影响 到 其 他 类 ， 因 此 
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增加 新 的 具体 命令 类 很 容易 ， 无 须 修 改 原 有 系统 源 代码 ， 甚 至 客户 类 代码 ， 满 足 “ 开 闭 原则 ”的 
要 求 。 


(3) 可 以 比较 容易 地 设计 一 个 命令 队列 或 宏 命 令 (组 合 命令 ) 。 
(4) 为 请 求 的 撤销 (Undo) 和 恢复 (Redo) 操 作 提 供 了 一 种 设计 和 实现 方案 。 
1. 主要 缺点 


命令 模式 的 主要 缺点 如 下 : 


怠 


使 用 命令 模式 可 能 会 导致 菜 些 系统 有 过 多 的 具体 命令 类 。 因 为 针对 每 一 个 对 请 求 接 收 者 的 调 
用 操 人 部 策 要 设计 一 个 具体 从 从 类 ， 因此 在 某 些 系统 中 可 能 需要 提供 大 量 的 具体 命令 类 ， 这 
将 影响 命令 模式 的 使 用 。 


适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 命令 模式 : 


(1) 系统 需要 将 请 求 调用 者 和 请 求 接收 者 解 耦 ， ， 使 得 调用 者 和 接收 者 不 直接 交互 。 请 求 调 用 者 
无 须知 道 接 收 者 的 存在 ， 也 无 须知 道 接 收 者 是 谁 ， 接 收 者 也 无 须 关 心 何 时 被 调用 。 


(2) 系统 需要 在 不 同 的 时 间 指定 请 求 、 将 请 求 排队 和 执行 请 求 。 一 个 命令 对 象 和 请 求 的 初始 调 
用 者 可 以 有 不 同 的 生命 期 ， 换 言 之 ， 最 初 的 请 求 发 出 者 可 能 已 经 不 在 了 ， 而 命令 对 象 本 身 仍 
en ee 而 无 须 关心 请 求 调用 者 的 存在 性 ， 可 
以 通过 请 求 日 志文 件 等 机 制 来 具体 实现 。 


(3) 系统 需要 支持 命令 的 撤销 (Undo) 操 作 和 恢复 (Redo) 操 作 。 
(4) 系统 需要 将 一 组 操作 组 合 在 一 起 形成 宏 命 令 。 
练习 


Sunny 软 件 公 司 欲 开发 一 个 基于 Windows 平 台 的 公告 板 系 统 。 该 系统 提供 了 一 个 主 菜 
(Menu)， 在 主 菜单 中 包含 了 一 些 菜 单项 (Menultem)， 可 以 通过 Menu 类 的 addMenultem( 方 
法 增加 菜单 项 。 菜 单项 的 主要 方法 是 click()， 每 一 个 菜单 项 包含 一 个 抽象 命令 类 ， 具 体 命 

令 类 包括 OpenCommand( 打 开 命 令 )，CreateCommand( 新 建 命令 )，EditCommand( 编 辑 命令 ) 
等 ， 命 令 类 类 具有 一 个 execute() 方 法 ， 用 于 调用 公告 板 系 统 界面 类 (BoardScreen) 的 open()、 
create()、 edit() 等 方法 。 试 使 用 命令 模式 设计 该 系统 ， 以 便 降 低 MenuIltem 类 与 BoardScreen 
类 之 问 的 耦合 度 。 
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解释 器 模式 -Interpreter Pattern 
解释 器 模式 -Interpreter Pattern 【学 习 难 度 : 龙 龙 友 女友 ， 使 用 频率 : 次 六 六 交 交 】 


。 解释 器 模式 -Interpreter Pattern 

自 定义 语言 的 实现 一 解释 器 模式 (一 
自 定义 语言 的 实现 解释 器 模式 

自 定义 语言 的 实现 解释 器 模式 











自 定 义 语言 的 实现 一 一 解释 器 模式 
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四 
自 定义 语言 的 实现 解释 器 模式 
自 定义 语言 的 实现 解释 器 模式 2 
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自 定义 语言 的 实现 一 一 解释 器 模式 (一 ) 


有 朋友 一 直 在 等 待 我 的 解释 器 模式 文稿 ， 微 笑 ， 现 把 某 个 版 本 发 在 博客 上 ， 欢 迎 大 家 讨论 ! 


虽然 目前 计算 机 编程 语言 有 好 几 百 种 ， 但 有 时 候 我 们 还 是 希望 能 用 一 些 简 单 的 语言 来 实现 一 
些 特定 的 操作 ， 我 们 只 要 向 计算 机 输入 一 个 句子 或 文件 ， 它 就 能 够 按照 预先 定义 的 文法 规则 
来 对 句子 或 文件 进行 解释 ， 从 而 实现 相应 的 功能 。 例 如 提供 一 个 简单 的 加 法 /减法 解释 器 ， 只 
要 输入 一 个 加 法 /减法 表达 式 ， 它 就 能 够 计算 出 表达 式 结果 ， 如 图 18-1 所 示 ， 当 输入 字符 串 表 
达 式 为 "1+2+3-4+12? 时 ， 将 输出 计算 结果 为 3。 


加 法 /减法 解释 硝 
输入 表达 式 : 
1+2+3 -4+1 





结果 显示 : 
3 











图 18-1 加 法 /减法 解释 器 示意 图 


我 们 知道 ， 像 C++、Java 和 C# 等 语言 无 法 直接 解释 类 似 “*1+2+3--4+12” 这 样 的 字符 串 (如 果 
直接 作为 数值 表达 式 时 可 以 解释 ) ， 我 们 必须 自己 定义 一 套 文法 规则 来 实现 对 这 些 语句 的 解 
释 ， 即 设计 一 个 自 定 义 语言 。 在 实际 开发 中 ， 这 些 简单 的 自 定义 语言 可 以 基于 现 有 的 编程 语 
言 来 设计 ， 如 果 所 基于 的 编程 语言 是 面向 对 象 语言 ， 此 时 可 以 使 用 解释 器 模式 来 实现 自 定义 


一 一 


语言 。 
18.1 机 器 人 控制 程序 


Sunny 软 件 公司 欲 为 茶 玩具 公司 开发 一 套 机 器 人 控制 程序 ， 在 该 机 器 人 控制 程序 中 包含 一 些 简 
单 的 美文 控制 指令 ， 每 一 个 指令 对 应 一 个 表达 式 (expression)， 该 表达 式 可 以 是 简单 表达 式 也 
可 以 是 复合 表达 式 ， 每 一 个 简单 表达 式 由 移动 方向 (direction)， 移动 方式 (action) 和 移动 距离 
(distance) 三 部 分 组 成 ， 其 中 移动 方向 包括 上 (up)、 下 (down)、 左 (left)、 右 (right) ; 移动 方式 包 
括 移动 (move) 和 快速 移动 (run) ; 移动 距离 为 一 个 正 整 数 。 两 个 表达 式 之 间 可 以 通过 与 (and) 连 
接 ， 形 成 复合 (composite) 表 达 式 。 


用 户 通 过 对 图 形 化 的 设置 界面 进行 操作 可 以 创建 一 个 机 器 人 控制 指令 ， 机 器 人 在 收 到 指令 后 
将 按照 指令 的 设置 进行 移动 ， 例 如 输入 控制 指令 : up move 5， 则 “向 上 移动 5 个 单位 ”; 输入 控 
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制 指令 : down run 10 and left move 20， 则 “向 下 快速 移动 10 个 单位 再 向 左 移动 20 个 单位 ”。 


Sunny 软 件 公司 开发 人 员 决 定 自 定 义 一 个 简单 的 语言 来 解释 机 器 人 控制 指令 ， 根 据 上 述 需求 描 
述 ， 用 形式 化 语言 来 表示 该 简单 语言 的 文法 规则 如 下 : 


expression ::= direction action distance | composite // 表 达 式 
composite ::= expression 'and' expression // 复 合 表达 式 
direction ::= 'up' | 'down' | 'left' | 'right' // 移 动 方向 
action ::= 'move' | 'run' // 移 动 方 式 

distance ::= an integer // 移 动 距离 


上 述 语言 一 共 定义 了 五 条 文法 规则 ， 对 应 五 个 语言 单位 ， 这 些 语言 单位 可 以 分 为 两 类 ， 一 类 
为 终结 符 (也 称 为 终结 符 表 达 式 ) ， 例 如 direction、action 和 distance， 它 们 是 语言 的 最 小 组 成 
单位 ， 不 能 再 进行 拆 分 ; 另 一 类 为 非 终结 符 (也 称 为 非 终结 符 表 达 式 ) ， 例 如 expression 和 
composite， 它 们 都 是 一 个 完整 的 甸子， 包含 一 系列 终结 符 或 非 终结 符 。 


我 们 根据 上 述 规 则 定义 出 的 语言 可 以 构成 很 多 语句 ， 计 算 机 程序 将 根据 这 些 语句 进行 某 种 操 
作 。 为 了 实现 对 语句 的 解释 ， 可 以 使 用 解释 器 模式 ， 在 解释 器 模式 中 每 一 个 文法 规则 都 将 对 
应 一 个 类 ， 扩 展 、 改 变 文法 以 及 增加 新 的 文法 规则 都 很 方便 ， 下 面 就 让 我 们 正式 进入 解释 器 
模式 的 学 习 ， 看 看 使 用 解释 器 模式 如 何 来 实现 对 机 器 人 控制 指令 的 处 理 。 
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18.2 文法 规则 和 抽象 语法 树 

解释 器 模式 描述 了 如 何 为 简单 的 语言 定义 一 个 文法 ， 如 何在 该 语言 中 表示 一 个 句子 ， 以 及 如 
何 解 释 这 些 句 子 。 在 正式 分 析 解 释 器 模式 结构 之 前 ， 我 们 先 来 学 习 如 何 表 示 一 个 语言 的 文法 
规则 以 及 如 何 构造 一 棵 抽象 语法 树 。 


在 前 面 所 提 到 的 加 法 /减法 解释 器 中 ， 每 一 个 输入 表达 式 ， 例 如 *1+2+3-4+1?， 都 包含 了 三 
个 语言 单位 ， 可 以 使 用 如 下 文法 规则 来 定义 : 


expression :;:= Value | operation 
operation ::= expression '+' expression | expression '-' expression 
value ::= an integer // 一 个 整数 值 


该 文法 规则 包含 三 条 语句 ， 第 一 条 表示 表达 式 的 组 成 方式 ， 其 中 value 和 operation 是 后 面 两 个 
语言 单位 的 定义 ， 每 一 条 语句 所 定义 的 字符 串 如 operation 和 value 称 为 语言 构造 成 分 或 语言 单 
位 ， 符 号 “::=” 表 示 “ 定 义 为 ”的 意思 ， 其 左边 的 语言 单位 通过 右边 来 进行 说 明和 定义 ， 语 言 单位 
对 应 终结 符 表达 式 和 非 终结 符 表达 式 。 如 本 规则 中 的 operation 是 非 终 结 符 表达 式 ， 它 的 组 成 元 
素 仍然 可 以 是 表达 式 ， 可 以 进一步 分 解 ， 而 Value 是 终结 符 表 达 式 ， 它 的 组 成 元 素 是 最 基本 的 
语言 单位 ， 不 能 再 进行 分 解 。 


在 文法 规则 定义 中 可 以 使 用 一 些 符 号 来 表示 不 同 的 含义 ， 如 使 用 <» 表示 或 ， 使 用 “{” 和 “}” 表 示 
组 合 ， 使 用 “*” 表 示 出 现 0 次 或 多 次 等 ， 其 中 使 用 频率 最 高 的 符号 是 表示 “或 ”关系 的 “|”， 如 文法 
规则 “boolValue ::= 0|1” 表 示 终 结 符 表 达 式 boolValue 的 取 值 可 以 为 0 或 者 1。 


除了 使 用 文法 规则 来 定义 一 个 语言 ， 在 解释 器 模式 中 还 可 以 通过 一 种 称 之 为 抽象 语法 树 
(Abstract Syntax Tree, AST) 的 图 形 方式 来 直观 地 表示 语言 的 构成 ， 每 一 棵 抽象 语法 树 对 应 一 个 
语言 实例 ， 如 加 法 /减法 表达 式 语 言 中 的 语 白 "1+2+3-4+1”， 可 以 通过 如 图 18-2 所 示 抽 象 语 
法 树 来 表示 : 
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图 18-2 抽象 语法 树 示 意图 


在 该 抽象 语法 树 中 ， 可 以 通过 终结 符 表 达 式 value 和 非 终 结 符 表 达 式 operation 组 成 复杂 的 语 

多， 每 个 文法 规则 的 语言 实例 都 可 以 表示 为 一 个 抽象 语 法 树 ， 即 每 一 条 具体 的 语 名 都 可 以 用 

类 似 图 18-2 所 示 的 抽象 语法 树 来 表示 ， 在 图 中 终结 符 表达 式 类 的 实例 作为 树 的 叶子 节点 ， 而 非 

终结 符 衣 达 式 类 的 实例 作为 非 叶 子 节点 ， 它 们 可 以 将 终结 符 表达 式 类 的 实例 以 及 包含 终结 符 

和 非 终结 符 实例 的 子 表达 式 作为 其 子 节点 。 抽 象 语法 树 描述 了 如 何 构成 一 个 复杂 的 句子 ， 通 
过 对 抽象 语法 树 的 分 析 ， 可 以 识别 出 语言 中 的 终结 符 类 和 非 终结 符 类 。 
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18.3 解释 器 模式 概述 


解释 器 模式 是 一 种 使 用 频率 相对 较 低 但 学 习 难 度 较 大 的 设计 模式 ， 它 用 于 描述 如 何 使 用 面向 
对 象 语 言 构成 一 个 简单 的 语言 解释 器 。 在 某 些 情况 下 ， 为 了 更 好 地 描述 某 一 些 特 定 类 型 的 问 
题 ， 我 们 可 以 创建 一 种 新 的 语言 ， 这 种 语言 拥有 自己 的 表达 式 和 结构 ， 即 文法 规则 ， 这 些 问 
题 的 实例 将 对 应 为 该 语言 中 的 句子 。 此 时 ， 可 以 使 用 解释 器 模式 来 设计 这 种 新 的 语言 。 对 解 
释 器 模式 的 学 习 能 够 加 深 我 们 对 面向 对 象 思 想 的 理解 ， 并 且 掌 握 编 程 语言 中 文法 规则 的 解释 
过 程 。 

解释 器 模式 定义 如 下 : 解释 器 模式 (Interpreter Pattern) : 定义 一 个 语言 的 文法 ， 并 且 建 立 一 个 
解释 器 来 解释 该 语言 中 的 句子 ， 这 里 的 “语言 "是 指使 用 规定 格式 和 语法 的 代码 。 解 释 器 模式 是 
一 种 类 行为 型 模式 。 


由 于 表达 式 可 分 为 终结 符 表 达 式 和 非 终结 符 表 达 式 ， 因 此 解释 器 模式 的 结构 与 组 合 模 式 的 结 
构 有 些 类 似 ， 但 在 解释 器 模式 中 包含 更 多 的 组 成 元 素 ， 它 的 结构 如 图 18-3 所 示 : 












+ interpret (Context ctx) 











中 
NonterminalExpression 


+ interpret (Context ctx) 


TerminalExpression 


+ interpret (Context ctx) 


图 18-3 解释 器 模式 结构 图 
在 解释 器 模式 结构 图 中 包含 如 下 几 个 角色 : 


@ AbstractExpression (抽象 表达 式 ) : 在 抽象 表达 式 中 声明 了 抽象 的 解释 操作 ， 它 是 所 有 终结 
符 表达 式 和 非 终 结 符 表达 式 的 公共 父 类 。 
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e TerminalExpression (终结 符 表 达 式 ) : 终结 符 表 达 式 是 抽象 表达 式 的 子 类 ， 它 实现 了 与 文法 
中 的 终结 符 相 关联 的 解释 操作 ， 在 句子 中 的 每 一 个 终结 符 都 是 该 类 的 一 个 实例 。 通 常 在 一 个 
解释 器 模式 中 只 有 少数 几 个 终结 符 表 达 式 类 ， 它 们 的 实例 可 以 通过 非 终 结 符 表 达 式 组 成 较为 
复杂 的 句子 。 


e NonterminalExpression ( 非 终结 符 表 达 式 ) : 非 终 结 符 表 达 式 也 是 抽象 表达 式 的 子 类 ， 它 实 
现 了 文法 中 非 终 结 符 的 解释 操作 ， 由 于 在 非 终结 符 表达 式 中 可 以 包含 终结 符 表达 式 ， 也 可 以 
继续 包含 非 终结 符 表达 式 ， 因 此 其 解释 操作 一 般 通 过 递归 的 方式 来 完成 。 

e@ Context (环境 类 ) : 环境 类 又 称 为 上 下 文 类 ， 它 用 于 存储 解释 器 之 外 的 一 些 全 局 信息 ， 通 
常 它 临 时 存储 了 需要 解释 的 语句 。 


在 解释 器 模式 中 ， 每 一 种 终结 符 和 非 终结 符 都 有 一 个 具体 类 与 之 对 应 ， 正 因为 使 用 类 来 表示 
每 一 条 文法 规则 ， 所 以 系统 将 具有 较 好 的 灵活 性 和 可 扩展 性 。 对 于 所 有 的 终结 符 和 非 终结 
符 ， 我 们 首先 需要 抽象 出 一 个 公共 父 类 ， 即 抽象 表达 式 类 ， 其 典型 代码 如 下 所 示 : 


abstract class AbstractExpression { 
public abstract void interpret(Context ctx); 


} 


终结 符 表达 式 和 非 终结 符 表 达 式 类 都 是 抽象 表达 式 类 的 子 类 ， 对 于 终结 符 表达 式 ， 其 代码 很 
简单 ， 主 要 是 对 终结 符 元 素 的 处 理 ， 其 典型 代码 如 下 所 示 : 


class TerminalExpression extends AbstractEXxpresslion { 
public void interpret(Context ctx) { 
// 终 结 符 表 达 式 的 解释 操作 
} 
} 


对 于 非 终结 符 表 达 式 ， 其 代码 相对 比较 复杂 ， 因 为 可 以 通过 非 终结 符 将 表达 式 组 合成 更 加 复 
杂 的 结构 ， 对 于 包含 两 个 操作 元 素 的 非 终结 符 表 达 式 类 ， 其 典型 代码 如 下 : 


class NonterminalExpression extends AbstractExpression { 
private AbstractExpression left; 
private AbstractExpression right; 


public NonterminalExpression(AbstractExpression left,Abstrac: 
this.1left=left; 
this.right=right; 

} 


public void interpret(Context ctx) { 
// 递 归 调 用 每 一 个 组 成 部 分 的 interpret() 方 法 
// 在 递归 调用 时 指定 组 成 部 分 的 连接 方式 ， 即 非 终结 符 的 功能 


} 


除了 上 述 用 于 表示 表达 式 的 类 以 外 ， 通 常 在 解释 器 模式 中 还 提供 了 一 个 环境 类 Context， 用 于 

存储 一 些 全 局 信息 ， 通 常 在 Context 中 包含 了 一 个 HashMap 或 ArrayList 等 类 型 的 集合 对 象 (也 可 

以 直接 由 HashMap 等 集合 类 充当 环境 类 ) ， 存 储 一 系列 公共 信息 ， 如 变量 名 与 值 的 映射 关系 
(key/value) 等 ， 用 于 在 进行 具体 的 解释 操作 时 从 中 获取 相关 信息 。 其 典型 代码 片段 如 下 : 


class Context { 

private HashMap map = new HashMap(); 

public void assign(String key, String value) { 
291 


// 往 环境 类 中 设 值 


} 
public String lookup(String key) { 
// 获 取 存 储 在 环境 类 中 的 值 


} 
} 
当 系 统 无 须 提供 全 局 公共 信息 时 可 以 省 略 环境 类 ， 可 根据 实际 情况 决定 是 否 需要 环境 类 。 
思考 


绘制 加 法 /减法 解释 器 的 类 图 并 编写 核心 实现 代码 。 
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为 了 能 够 解释 机 器 人 控制 指令 ，Sunny 软 件 公 司 开 发 人 员 使 用 解释 器 模式 来 设计 和 实现 机 器 人 
控制 程序 。 针 对 五 条 文法 规则 ， 分 别提 供 五 个 类 来 实现 ， 其 中 终结 符 表 达 式 direction、action 
和 distance 对 应 DirectionNode 类 、ActionNode 类 和 DistanceNode 类 ， 非 终结 符 表 达 式 expression 
和 composite 对 应 SentenceNode 类 和 AndNode 类 。 


我 们 可 以 通过 抽象 语法 树 来 表示 具体 解释 过 程 ， 例 如 机 器 人 控制 指令 “down run 10 and left 


move 20” 对 应 的 抽象 语法 树 如 图 18-4 所 示 : 
DirectionNode 
down 


ActionNode 


ActionNode 

























SentenceNode 
















AndNode 








SentenceNode 












图 18-4 机 器 人 控制 程序 抽象 语法 树 实 例 


机 器 人 控制 程序 实例 基本 结构 如 图 18-5 所 示 : 
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+ ActionNode (String action) 
+ interpret () : String 














AbstractNode action, 
AbstractNode distance) 
+ intempret () 





DistanceNode 


- distance : String 
+ DistanceNode (String distance) 
+ interpret () 






: String 





图 18-5 机 器 人 控制 程序 结构 图 


在 图 18-5 中 ，AbstractNode 充 当 抽 和 象 表达 式 角 色 ，DirectionNode、ActionNode 和 DistanceNode 充 
当 终 结 符 表 达 式 角色 ，AndNode 和 SentenceNode 充 当 非 终结 符 表 达 式 角色 。 完 整 代码 如 下 所 
示 : 


// 注 : 本 实例 对 机 器 人 控制 指令 的 输出 结果 进行 模拟 ， 将 英文 指令 翻译 为 中 文 指令 ， 实 际 情况 
import java.util.*; 


// 抽 象 表达 式 
abstract class AbstractNode { 
public abstract String interpret(); 


} 


//And 解 释 : 非 终 结 符 表 达 式 

class AndNode extends AbstractNode { 
private AbstractNode left; //And 的 左 表达 式 
private AbstractNode right; //And 的 右 表达 式 


public AndNode(AbstractNode left, AbstractNode right) { 
this.1left = left; 
this.right = right; 

} 


//And 表 达 式 解释 操作 
public String interpret() { 
return left.interpret() + "再 " + right.interpret(); 
} 
} 


// 简 单 句 子 解释 : 非 终 结 符 表达 式 

class SentenceNode extends AbstractNode { 
private AbstractNode direction; 
private AbstractNode action; 
private AbstractNode distance; 
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public SentenceNode(AbstractNode direction,AbstractNode actiony Al 
this.direction = direction; 
this.action = action; 
this.distance = distance; 


} 


// 简 单 句 子 的 解释 操作 
public String interpret() { 

return direction,interpret() + action,.interpret() + distance 
} 


} 


// 方 向 解释 : 终结 符 表 达 式 
class DirectionNode extends AbstractNode { 
private String direction; 


public DirectionNode(String direction) { 
this.direction = direction; 
} 


// 方 向 表达 式 的 解释 操作 
public String interpret() { 
if (direction.equalsIgnoreCase("up")) { 
return "向 上 "; 


else if (direction.equalsIgnoreCase("down")) { 
return "向 下 "， 


else if (direction.equalsIgnoreCase("left")) { 
return "向 左 "， 


else if (direction.equalsIgnoreCase("right")) { 
return "向 右 "， 


} 
else { 

return "无 效 指令 "， 
} 


} 


// 动 作 解 释 : 终结 符 表达 式 
class ActionNode extends AbstractNode { 
private String action; 


public ActionNode(String action) { 
this.action = action; 
} 


// 动 作 (移动 方式 ) 表达 式 的 解释 操作 
public String interpret() { 
if (action.equalsIgnoreCase("move")) { 
return "移动 "， 
} 
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} 


else if (action.equalsIgnoreCase("run")) { 
return "快速 移动 "， 


} 


else { 


return "无 效 指令 "， 


} 


// 距 离 解释 : 终结 符 表 达 式 
class DistanceNode extends AbstractNode { 
private String distance,; 


public DistanceNode(String distance) { 


} 


this.distance = distance; 


// 距 离 表达 式 的 解释 操作 
public String interpret() { 


} 


} 


return this.distance; 


// 指 令 处 理 类 : 工具 类 
class InstructionHandler { 


for 


private String instruction; 
private AbstractNode node; 


public void handle(String instruction) { 
AbstractNode left = null, right = null; 
AbstractNode direction = null, action = null, distance = nul 
Stack stack = new Stack(); // 声 明 一 个 栈 对 象 用 于 存储 抽象 语法 树 
String[] words = instruction.split(" "); // 以 空格 分 隔 指 令 字 符 串 
(int i = 0; i < words.length; i++) { 


// 本 实例 采用 栈 的 方式 来 处 理 指 令 ， 如 果 遇 到 “and”， 则 将 其 后 的 三 个 单词 作为 三 个 终结 符 表 
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left = (AbstractNode)stack.pop(); // 弹 出 栈 顶 表达 式 作为 左 
String word1= words[++i]; 

direction = new DirectionNode(word1); 

String word2 = words[++i]; 

action = new ActionNode(word2); 

String word3 = words[++i]; 

distance = new DistanceNode(word3); 

right = new SentenceNode(direction,action,distance); 
stack.push(new AndNode(left,right)); // 将 新 表达 式 压 入 栈 


} 
// 如 果 是 从 头 开 始 进行 解释 ， 则 将 前 三 个 单词 组 成 一 个 简单 句子 SentenceN 
else { 


String word1 = words[i]; 

direction = new DirectionNode(word1); 
String word2 = words[++i]; 

action = new ActionNode(word2); 
String word3 = words[++i]; 

distance = new DistanceNode(word3); 
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} 


工 
A 


left = new SentenceNode(direction,action,distance); 
stack.push(left); // 将 新 表达 式 压 入 栈 中 
} 
} 
this.node = (AbstractNode)stack.pop(); // 将 全 部 表达 式 从 栈 中 弹出 
} 


public String output() { 
String result = node.interpret(); // 解 释 表达 式 
return result; 


具 类 InstructionHandler 用 于 对 输入 指令 进行 处 理 ， 将 输入 指令 分 割 为 字符 串 数 组 ， 将 第 1 
、 第 2 个 和 第 3 个 单词 组 合成 一 个 句子 ， 并 存 入 栈 中 ; 如 果 发 现 有 单词 “and”， 则 将 “and” 后 的 


第 1 个 、 第 2 个 和 第 3 个 单词 组 合成 一 个 新 的 句子 作为 “and” 的 右 表达 式 ， 并 从 栈 中 取出 原先 所 存 
多 子 作为 左 表 达 式 ， 然 后 组 合成 一 个 And 节 点 存 入 栈 中 。 依 此 类 推 ， 直 到 整个 指令 解析 结 


编写 如 下 客户 端 测试 代码 : 


class Client { 


} 


public static void main(String args[]) { 
String instruction = "up move 5 and down run 10 and left mov' 
InstructionHandler handler = new InstructionHandler(); 
handler .handle(instruction); 
String outString; 
outString = handler.output(); 
System.out.println(outString); 


编译 并 运行 程序 ， 输 出 结果 如 下 : 
向 上 移动 5 再 向 下 快速 移动 10 再 向 左 移动 5 
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自 定义 语言 的 实现 一 一 解释 器 模式 (五 ) 
自 定 义 语言 的 实现 一 解释 器 模式 (五 ) 


18.5 再 谈 Context 的 作用 


在 解释 器 模式 中 ， 环 境 类 Context 用 于 存储 解释 器 之 外 的 一 些 全 局 信息 ， 它 通常 作为 参数 被 传 

递 到 所 有 表达 式 的 解释 方法 interpret() 中 ， 可 以 在 Context 对 象 中 存储 和 访问 表达 式 解 释 器 的 状 

态 ae 提供 一 些 全 局 的 、 公 共 的 数据 ， 此 外 还 可 以 在 Context 中 增加 一 些 所 有 表 
达 式 解释 器 共有 的 功能 ， 减 轻 解释 器 的 职责 。 


在 上 面 的 机 器 nn ， 我 们 省 略 了 环境 类 角色 ， 下 面 再 通过 一 个 简单 实例 来 说 明 
环境 类 的 用 途 


Sunny 软 件 公司 开发 了 一 套 简单 的 基于 字符 界面 的 格式 化 指令 ， 可 以 根据 输入 的 指令 在 字符 界 
面 中 输出 一 些 格式 化 内 容 ， 例 如 输入 “LOOP 2 PRINT 杨 过 SPACE SPACE PRINT 小 龙 女 
BREAK END PRINT 郭 请 SPACE SPACE PRINT 黄 营 ”, 将 输出 如 下 结果 : 


杨过 小龙 女 
杨过 ”小龙 女 
郭靖 。 黄蓉 


其 中 关键 词 LOOP 表 示 “ 循 环 ”， 后 面 的 数字 表示 循环 次 数 ; PRINT 表 示 “ 打 印 ”， 后 面 的 字符 串 
表示 打印 的 内 容 ; SPACE 表示“ 空格 ”; BREAK 表 示 “ 换 行 ” ;END 表示 “循环 结束 ”。 每 一 个 关 
键 词 对 应 一 条 命令 ， 计 算 机 程序 将 根据 关键 词 执行 相应 的 处 理 操作 。 


现 使 用 解释 器 模式 设计 并 实现 该 格式 化 指令 的 解释 ， 对 指令 进行 分 析 并 调用 相应 的 操作 执行 
指令 中 千 二 条 命令 3 


Sunny 软 件 公司 开发 人 员 通 过 分 析 ， 根 据 该 格式 化 指令 中 句子 的 组 成 ， 定 义 了 如 下 文法 规则 : 


expression ::= command* // 表 达 式 ， 0 含 多 条 命令 

command ::= loop | primitive // 语 句 命 

loop ::= 'loopnumber' expression ena // 循 环 命令 ， 其 中 number 为 自然 数 
primitive ::= 'printstring' | 'space' | 'break' // 基 本 命令 ， 其 中 Strinc 


根据 以 上 文法 规则 ， 通 过 进一步 分 析 ， 绘 制 如 图 18-6 所 示 结 构图 : 
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- tokenizer :StringTokenizer 
- currentT oken : String 


+ Context (String text) 


+ nextToken () - String 
+ CurrentToken () :String 
+ SkipToken (String token) : void 
+ currentNumber () -int 














CommandNode 


Node 
{abstract} 
| = 
+ interpret (Context context) : void 
+ execute () : void 


“|+ interpret (Context context) :void 


+ execute () -void 


臣 
LoopCommandNode ExpressionNode 
- Number -int - list : ArrayList<Node> 


- commandNode - Node + interpret (Context context) : void 
+ interpret (Context context) : void + Execute () - void 
+ Execute () : void 
























PrimiiveCommandNode 


- name : String 
- text :String 
+ interpret (Context context) : void 
+ execute () : void 





图 18-6 格式 化 指令 结构 图 


在 图 18-6 中 ，Context 充 当 环 境 角 色 ，Node 充 当 抽 象 表达 式 角色 ，ExpressionNode、 
CommandNode 和 LoopCommandNode 充 当 非 终结 符 表达 式 角色 ，PrimitiveCommandNode 充 当 终 
结 符 表达 式 角 色 。 完 整 代码 如 下 所 示 : 


import java.util.*; 


// 环 境 类 : 用 于 存储 和 操作 需要 解释 的 语句 ， 在 本 实例 中 每 一 个 需要 解释 的 单词 可 以 称 为 一 个 
class Context { 
private StringTokenizer tokenizer; //StringTokenizer 类 ， 用 于 将 字符 : 
private String currentToken; // 当 前 字符 串 标 记 


public Context(String text) { 
tokenizer = new StringTokenizer(text); // 通 过 传 入 的 指令 字符 串 创 到 
nextToken( ); 


} 


// 返 回 下 一 个 标记 
public String nextToken() { 
If (tokenizer.hasMoreTokens()) { 
currentToken = tokenizer.nextToken(); 
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} 
else { 

currentToken = null; 
} 


return currentToken; 


} 


// 返 回 当前 的 标记 
public String currentToken() { 
return currentToken; 


} 


// 跳 过 一 个 标记 
public void skipToken(String token) { 
if (!token.equals(currentToken)) { 
System.err.println(" 错 误 提示 :" + currentToken + "解释 错误 ! 
} 


nextToken( ); 


} 


// 如 果 当 前 的 标记 是 一 个 数字 ， 则 返回 对 应 的 数值 
public int currentNumber() 1{ 
int number = 0; 


tryt{ 
number = Integer.parseInt(currentToken); // 将 字符 串 转 换 为 整 


catch(NumberFormatException e) { 
System.err.println(" 错 误 提示 :" + e); 
} 


return number; 


} 


// 抽 象 节点 类 : 抽象 表达 式 

abstract class Node { 
public abstract void interpret(Context text); // 声 明 一 个 方法 用 于 解释 
public abstract void execute(); // 声 明 一 个 方法 用 于 执行 标记 对 应 的 命令 


// 表 达 式 节点 类 : 非 终结 符 表 达 式 
class ExpressionNode extends Node { 
private ArrayList<Node> list = new ArrayList<Node>(); // 定 义 一 个 集 


public void interpret(Context context) { 
// 循 环 处 理 Context 中 的 标记 
while (true)t{ 
// 如 果 已 经 没有 任何 标记 ， 则 退出 解释 
if (context,currentToken() == null) { 
break; 


} 

// 如 果 标 记 为 END， 则 不 解释 END 并 结束 本 次 解释 过 程 ， 可 以 继续 之 后 的 解释 

else if (context.currentToken().equals("END")) { 
context.skipToken("END"); 
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break; 


} 

// 如 果 为 其 他 标记 ， 则 解释 标记 并 将 其 加 入 命令 集合 

else { 
Node commandNode = new CommandNode(); 
commandNode.interpret(context); 
list.add(commandNode); 


} 


// 循 环 执行 命令 集合 中 的 每 一 条 命令 
public void execute() { 
Iterator iterator = list.iterator(); 
while (iterator.hasNext())t{ 
((Node)iterator.next()).execute(); 
} 


} 


// 语 名 命令 节点 类 : 非 终结 符 表 达 式 
class CommandNode extends Node { 
private Node node; 


public void Lerhy ee (con ex context) { 
// 处 理 LOOP 循 环 命令 
if (context.currentToken().equals("LOOP")) { 
node = new LoopCommandNode( ); 
node.interpret(context); 


} 

// 处 理 其 他 基本 命令 

else { 
node = new PrimitiveCommandNode(); 
node.interpret(context); 


} 


public void execute() { 
node.execute( ); 
} 


} 


// 循 环 命令 节点 类 : 非 终结 符 表 达 式 
class LoopCommandNode extends Node { 
private int number; // 循 环 次 数 
private Node commandNode; // 循 环 语句 中 的 表达 式 


// 解 释 循环 命令 

public void interpret(Context context) { 
context.skipToken("LOOP"); 
number = context.currentNumber(); 
context ,nextToken( ); 


commandNode = new ExpressionNode(); // 循 环 语 多 中 的 表达 式 
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commandNode.interpret(context); 


} 


public void execute() { 
for (int i=0;i<number;i++) 
commandNode.execute( ); 


} 


// 基 本 命令 节点 类 : 终结 符 表 达 式 

class PrimitiveCommandNode extends Node { 
private String name; 
private String text; 


// 解 释 基 本 命令 
public void interpret(Context context) { 
name = context.currentToken(); 
context.skipToken(nanme); 
If (!name.equals("PRINT") && Iname.equals("BREAK") && Iname.'! 
System.err.println(" 非 法 命令 1 ")， 
} 


If (name.equals("PRINT")){ 
text = context.currentToken(); 
context ,nextToken( ); 


} 


public void execute( ){ 
If (name.equals("PRINT")) 
System.out.print(text); 
else if (name.equals("SPACE")) 
System.out.print(™" "); 
else if (name.equals("BREAK")) 
System,out,printJln()， 


} 


在 本 实例 代码 中 ， 环 境 类 Context 类 似 一 个 工具 类 ， 它 提供 了 用 于 处 理 指令 的 方法 ， 如 
nextToken()、currentToken()、skipToken() 等 ， 同 时 它 存储 了 需要 解释 的 指令 并 记录 了 每 一 次 解 
释 的 当前 标记 (Token) ， 而 具体 的 解释 过 程 交 给 表达 式 解释 器 类 来 处 理 。 我 们 还 可 以 将 各 种 解 
释 器 类 包含 的 公共 方法 移 至 环境 类 中 ， 更 好 地 实现 这 些 方法 的 重用 和 扩展 。 


针对 本 实例 代码 ， 我 们 编写 如 下 客户 端 测试 代码 : 


class Client{ 
public static void main(String[] args)t 
String text = "LOOP 2 PRINT 杨过 SPACE SPACE PRINT 小 龙 女 BREA 
Context context = new Context (text); 


Node node = new ExpressionNode(); 


node.interpret(context); 
node.execute( ); 
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} 

编译 并 运行 程序 ， 输 出 结果 如 下 : 
杨过 小 龙 女 

杨过 小 龙 女 

郭靖。 黄 蕉 

本 


心 


预测 指令 “LOOP 2 LOOP 2 PRINT 杨 过 SPACE SPACE PRINT 小 龙 女 BREAK END PRINT 
郭靖 SPACE SPACE PRINT 黄蓉 BREAK END” 的 输出 结果 。 
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自 定义 语言 的 实现 一 一 解释 器 模式 (六 ) 
自 定义 语言 的 实现 一 一 解释 器 模式 (六 ) 


18.6 解释 器 模式 总 结 
解释 器 模式 为 自 定 义 语言 的 设计 和 实现 提供 了 一 种 解决 方案 ， 它 用 于 定义 一 组 文法 规则 并 通 
过 这 组 文法 规则 来 解释 语言 中 的 句子 。 虽 然 解释 器 模式 的 使 用 频率 不 是 特别 高 ， 但 是 它 在 正 
则 表达 式 、XMEL 文 档 解 释 等 领域 还 是 得 到 了 广泛 使 用 。 与 解释 器 模式 类 似 ， 目 前 还 诞生 了 很 
多 基于 抽象 语法 树 的 源 代码 处 理工 具 ， 例 如 Eclipse 中 的 Eclipse AST， 它 可 以 用 于 表示 Java 语 言 
的 语法 结构 ， 用 户 可 以 通过 扩展 其 功能 ， 创 建 自己 的 文法 规则 。 

1. 主要 优点 
解释 器 模式 的 主要 优点 如 下 : 


(1) 易于 改变 和 扩展 文法 。 由 于 在 解释 器 模式 中 使 用 类 来 表示 语言 的 文法 规则 ， 因 此 可 以 通过 
继承 等 机 制 来 改变 或 扩展 文法 。 


(2) 每 一 条 文法 规则 都 可 以 表示 为 一 个 类 ， 因 此 可 以 方便 地 实现 一 个 简单 的 语言 。 


(3) 实现 文法 较为 容易 。 在 抽象 语法 树 中 每 一 个 表达 式 节点 类 的 实现 方式 都 是 相似 的 ， 这 些 类 
的 代码 编写 都 不 会 特别 复杂 ， 还 可 以 通过 一 些 工具 自动 生成 节点 类 代码 。 


(4) 增加 新 的 解释 表达 式 较为 方便 。 如 果 用 户 需要 增加 新 的 解释 表达 式 只 需要 对 应 增加 一 个 新 
的 终结 符 表达 式 或 非 终结 符 表达 式 类 ， 原 有 表达 式 类 代码 无 须 修改 ， 符 合 “ 开 闭 原则 ”。 


1. 主要 缺点 
解释 器 模式 的 主要 缺点 如 下 : 
(1) 对 于 复杂 文法 难以 维护 。 在 解释 器 模式 中 ， 每 一 条 规则 至 少 需要 定义 一 个 类 ， 因 此 如 果 一 
个 语言 包含 太 多 文法 规则 ， 类 的 个 数 将 会 急剧 增加 ， 导 致 系统 难以 管理 和 维护 ， 此 时 可 以 考 
虑 使 用 语法 分 析 程 序 等 方式 来 取代 解释 器 模式 。 


(2) 执行 效率 较 低 。 由 于 在 解释 器 模式 中 使 用 了 大 量 的 循环 和 递归 调用 ， 因 此 在 解释 较为 复杂 
的 句子 时 其 速度 很 慢 ， 而 且 代 码 的 调试 过 程 也 比较 麻烦 。 


1. 适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 解释 器 模式 : 
(1) 可 以 将 一 个 需要 解释 执行 的 语言 中 的 句子 表示 为 一 个 抽象 语法 树 。 
(2) 一 些 重 复出 现 的 问题 可 以 用 一 种 简单 的 语言 来 进行 表达 。 
(3) 一 个 语言 的 文法 较为 简单 。 


(4) 执行 效率 不 是 关键 问题 。【 注 : 高 效 的 解释 器 通常 不 是 通过 直接 解释 抽象 语法 树 来 实现 
的 ， 而 是 需要 将 它们 转换 成 其 他 形式 ， 使 用 解释 器 模式 的 执行 效率 并 不 高 。】 


练习 


304 


自 定义 语言 的 实现 ~ 解释 器 模式 (六 


Sunny 软 件 公司 欲 为 数据 库 备 份 和 同步 开发 一 套 简 单 的 数据 库 同 步 指 令 ， 通 过 指令 可 以 对 
数据 库 中 的 数据 和 结构 进行 备份 ， 例 如 ， 输 入 指令 “COPY VIEW FROM srcDB TO 
desDB” 表 示 将 数据 库 srcDB 中 的 所 有 视图 (View) 对 象 都 拷贝 至 数据 库 desDB ; 输入 指 

令 “MOVE TABLE Student FROM srcDB TO desDB” 表 示 将 数据 库 srcDB 中 的 Student 表 移动 
至 数据 库 desDB。 试 使 用 解释 器 模式 来 设计 并 实现 该 数据 库 同步 指令 。 


【 注 : 本 练习 是 2010 年 我 在 给 某 公 司 进行 设计 模式 内 训 时 该 公司 正在 开发 的 一 个 小 工具 1 】 
解释 器 模式 可 以 说 是 所 有 设计 模式 中 难度 较 大 、 使 用 频率 较 低 的 一 个 模式 ， 如 果 您 能 够 静 下 
心 来 把 这 几 篇 文章 都 看 完 ， 我 相信 您 对 解释 器 模式 应 该 有 了 一 个 较为 全 面 的 了 解 ， 欢 迎 大 家 
与 我 交流 和 讨论 。 


感谢 您 能 够 坚持 看 完 这 六 篇 关于 解释 器 模式 的 文章 
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迭代 器 模式 -Iterator Pattern 【学 习 难 度 : 龙 友 丰 六 衣 ， 使 用 频率 : 交友 交友 克 】 


e 迭代 器 模式 -Iterator Pattern 
o 遍历 聚合 对 的 元 素 ” ”和 迭代 器 模式 (一 
遍历 聚合 对 的 元 素 - ”和 迭代 器 模式 
遍历 聚合 对 的 元 素 - ”人 和 迭代 器 模式 














遍历 聚合 对 的 元 素 一 一 迭代 器 模式 
遍历 聚合 对 的 元 素 一 渤 代 儿 模 式 《 六 





的 元 素 一 一 选 代 器 模式 《四 
这 


O 0O oO oOo o 
局 
3 
NS 
为 
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遍历 聚合 对 得 中 的 元 素 一 一 和 迭代 绒 模 式 〈 一 ) 
遍历 聚合 对 和 象 中 的 元 素 一 一 和 迭代 问 模 式 〈 一 ) 


20 世 纪 80 年 代 ， 那 时 我 家 有 一 人 台 “ 古 老 的 ”电视 机 ， 上 牌子 我 忘 了 ， 只 记得 是 台 黑 白 电 视 机 ， 没 有 
选 拉 吕 ， 每 次 开关 机 或 者 换 台 都 需要 通过 电视 机 上 面 的 那些 按钮 来 完成 ， 我 印象 最 深 的 是 那 
个 用 来 换 台 的 按钮 ， 需 要 亲自 用 手 去 旋转 (还 要 使 点 劲 才能 打动 ) ， 每 转 一 下 就 “ 啦 ” 的 响 一 
声 ， 如 果 没 有 收 到 任何 电视 频道 就 会 出 现 一 片 让 人 有 眼花 的 雪花 点 。 当 然 ， 电 视 机 上 面 那 两 根 
可 以 前 后 左右 移动 ， 并 外 E 够 变 长 变 短 的 天 线 也 是 当年 电视 机 的 标志 性 部 件 之 一 ， 我 记得 小 时 
候 每 次 画 电 视 机 时 一 定 要 画 那 两 根 天 线 ， 要 不 总 觉得 不 是 电视 机 。 随 着 科技 的 飞速 发 展 ， 越 
来 越 高 级 的 电视 机 相继 出 现 ， 那 种 古老 的 电视 机 已 经 很 少 能 够 看 到 了 。 与 那 时 的 电视 机 相 
比 ， 现 今 的 电视 机 给 我 们 带 来 的 最 大 便利 之 一 就 是 增加 了 电视 机 中 控 器 ， 我 们 在 进行 开机 、 
关机 、 换 台 、 改 变 音 量 等 操作 时 都 无 须 直接 操作 电视 机 ， 可 以 通过 遂 控 器 来 间接 实现 。 我 们 
可 以 将 电视 机 看 成 一 个 存储 电视 频道 的 集合 对 象 ， 通 过 膛 控 器 可 以 对 电视 机 中 的 电视 频道 集 
合 进行 操作 ， 如 返回 上 一 个 频道 、 跳 转 到 下 一 个 频道 或 者 跳 转 至 指定 的 频道 。 膛 控 器 为 我 们 
操作 电视 频道 带 来 很 大 的 方便 ， 用 户 并 不 需要 知道 这 些 频道 到 底 如 何 存储 在 电视 机 中 。 电 视 
机 路 控 器 和 电视 机 示意 图 如 图 1 所 示 : 





图 1 电视 机 唤 控 器 与 电视 机 示意 图 


在 软件 开发 中 ， 也 存在 大 量 类 似 电 视 机 一 样 的 类 ， 它 们 可 以 存储 多 个 成 员 对 象 (元 素 ) ， 这 
些 类 通常 称 为 聚合 类 (Aggregate Classes)， 对 应 的 对 象 称 为 聚合 对 象 。 为 了 更 加 方便 地 操作 这 
些 聚 合 对 象 ， 同 时 可 以 很 灵活 地 为 聚合 对 象 增加 不 同 的 遍历 方法 ， 我 们 也 需要 类似 电视 机 到 
控 器 一 样 的 角色 ， 可 以 访问 一 个 聚合 对 象 中 的 元 素 但 又 不 需要 暴露 它 的 内 部 结构 。 本 章 我 们 
将 要 学 习 的 迭代 器 模式 将 为 聚合 对 象 提供 一 个 中 控 嚣 ， 通 过 引入 迭代 器 ， 客 户 端 无 须 了 解 聚 
合 对 象 的 内 部 结构 即 可 实现 对 聚合 对 象 中 成 员 的 遍历 ， 还 可 以 根据 需要 很 方便 地 增加 新 的 遍 
历 方式 。 

1 销售 管理 系统 中 数据 的 遍历 

Sunny 软 件 公司 为 某 商 场 开 发 了 一 套 销 售 管理 系统 ， 在 对 该 系统 进 和 分 析 和 设计 时 ， Sunny 软 


件 公司 开发 人 员 发 现 经 常 需要 对 系统 中 的 商品 数据 、 客 户 数据 等 进行 遍历 ， 为 了 复 用 这 些 遍 
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历代 码 ，Sunny 公 司 开发 人 员 设 计 了 一 个 抽象 的 数据 集合 类 AbstractObjectList， 而 将 存储 商品 
和 客户 等 数据 的 类 作为 其 子 类 ，AbstractObjectList 类 结构 如 图 2 所 示 : 





图 2 AbstractObjectList 类 结构 图 
在 图 2 中 ，List 类 型 的 对 象 objects 用 于 存储 数据 ， 方 法 说 明 如 表 1 所 示 : 表 1 AbstractObjectList 
类 方法 说 明 

移 到 FF 一 个 F 素 


next() 移 全 下 一 个 元 素 


isLast0 册 断 当前 元 素 是 否 是 最 后 一 个 元 素 
previous() 移 至 上 一 个 元 素 
isFirst) ”出 断 当前 元 素 是 否 是 第 一 个 元 素 





AbstractObjectList 类 的 子 类 ProductList 和 CustomerList 分 别 用 于 存储 商品 数据 和 客户 数据 。 


Sunny 软 件 公司 开发 人 员 通 过 对 AbstractObjectList 类 结构 进行 分 析 ， 发 现 该 设计 方案 存在 如 下 
几 个 问题 : 


(1) 在 图 2 所 示 类 图 中 ，addObject()、removeObject() 等 方法 用 于 管理 数据 ， 而 next()、isLast()、 
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previous()、isFirst() 等 方法 用 于 遍历 数据 。 这 将 导致 聚合 类 的 职责 过 重 ， 它 既 负 责 存 储 和 管理 
数据 ， 又 负责 遍历 数据 ， 违 反 了 "单一 职责 原则 ”， 由 于 聚合 类 非常 庞大 ， 实 现代 码 过 长 ， 还 将 
给 测试 和 维护 增加 难度 。 


(2) 如 果 将 抽象 聚合 类 声明 为 一 个 接口 ， 则 在 这 个 接口 中 充斥 着 大 量 方法 ， 不 利于 子 类 实现 ， 
违反 了 “接口 隔离 原则 ”。 


(3) 如 果 将 所 有 的 人 遍历 操作 都 交 给 子 类 来 实现 ， 将 导致 子 类 代码 庞大 ， 而 且 必 须 暴 露 
AbstractObjectList 的 内 部 存储 细节 ， 向 子 类 公开 自己 的 私有 了 属性， 否则 子 类 无 法 实施 对 数据 的 
遍历 ， 这 将 破坏 AbstractObjectList 类 的 封装 性 。 


如 何 解决 上 述 问 题 ? 解决 方案 之 一 就 是 将 聚合 类 中 负责 遍历 数据 的 方法 提取 出 来 ， 封 装 到 专 


门 的 类 中 ， 实 现 数据 存储 和 数据 遍历 分 离 ， 无 须 暴 露 聚 合 类 的 内 部 属性 即 可 对 其 进行 操作 ， 
而 这 正 是 迭代 器 模式 的 意图 所 在 。 
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遍历 聚合 对 象 中 的 元 率 
遍历 聚合 对 象 中 的 元 素 


2 和 迭代 器 模式 概述 


在 软件 开发 中 ， 我 们 经 常 需要 使 用 聚合 对 象 来 存储 一 系列 数据 。 聚 合 对 象 拥有 两 个 职责 : 一 
是 存储 数据 ; 二 是 遍历 数据 。 从 依赖 性 来 看 ， 前 者 是 聚合 对 象 的 基本 职责 ; 而 后 者 既是 可 变 
化 的 ， 又 是 可 分 离 的 。 因 此 ， 可 以 将 遍历 数据 的 行为 从 聚合 对 象 中 分 离 出 来 ， 封 装 在 一 个 被 
称 之 为 "迭代 器 "的 对 象 中 ， 由 和 克 代 器 来 提供 遍历 聚合 对 象 内 部 数据 的 行为 ， 这 将 简化 聚合 对 象 
的 设计 ， 更 符合 "单一 职责 原则 ”的 要 求 。 


迭代 器 模式 定义 如 下 : 


迭代 器 模式 (二) 
迭代 器 模式 (二) 





和 迭代 器 模式 (Iterator Pattern) : 提供 一 种 方法 来 访问 聚合 对 象 ， 而 不 用 暴露 这 个 对 象 的 内 部 表 
示 ， 其 别名 为 游标 (Cursor。 迁 代 器 模式 是 一 种 对 象 行为 型 模式 。 


在 近代 器 模式 结构 中 包含 聚合 和 迭代 器 两 个 层次 结构 ， 考 虑 到 系统 的 灵活 性 和 可 扩展 性 ， 在 
迭代 器 模式 中 应 用 了 工厂 方法 模式 ， 其 模式 结构 如 图 3 所 示 : 


lterator 


+ first () 


Aggregate 


+ _ next () 
+ hasNext () 
+ currentltem () 





+ createlterator () 
人 














Concretelterator 


+ first () 

+ next () 

+ hasNext () 

+ currentltem () 







ConcreteAggregate 
+ createlterator () 






aggregate 


图 3 迭代 器 模式 结构 图 
在 和 迭代 器 模式 结构 图 中 包含 如 下 几 个 角色 : 
e@ Iterator (抽象 迭代 器 ) : 它 定 义 了 访问 和 遍历 元 素 的 接口 ， 声 明了 用 于 遍历 数据 元 素 的 方 
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法 ， 例 如 : 用 于 获取 第 一 个 元 素 的 first() 方 法 ， 用 于 访问 下 一 个 元 素 的 next() 方 法 ， 用 于 判断 是 
否 还 有 下 一 个 元 素 的 hasNext0 〇 方法， 用 于 获取 当前 元 素 的 currentItem() 方 法 等 ， 在 具体 迭代 器 
中 将 实现 这 些 方法 。 


e@ Concretejterator ( 具体 迭代 器 ) : 它 实 现 了 抽象 迭代 器 接口 ， 完 成 对 聚合 对 象 的 遍历 ， 同 时 
在 具体 迭代 器 中 通过 游标 来 记录 在 聚合 对 象 中 所 处 的 当前 位 置 ， 在 具体 实现 时 ， 游 标 通 常 是 
一 个 表示 位 置 的 非 负 整数 。 


e Aggregate (抽象 聚合 类 ) : 它 用 于 存储 和 管理 元 素 对 象 ， 声 明 一 个 createlterator() 方 法 用 于 
创建 一 个 达 代 器 对 象 ， 充 当 抽象 办 代 器 工厂 角色 。 


e ConcreteAggregate (具体 聚合 类 ) : 它 实 现 了 在 抽象 聚合 类 中 声明 的 createIterator() 方 法 ， 该 
方法 返回 一 个 与 该 具体 聚合 类 对 应 的 具体 迭代 器 Concretelterator 实 例 。 


在 迭代 器 模式 中 ， 提 供 了 一 个 外 部 的 移 代 器 来 对 聚合 对 象 进行 访问 和 遍历 ， 迭 代 器 定义 了 一 
个 访问 该 聚合 元 素 的 接口 ， 并 且 可 以 跟踪 当前 遍历 的 元 素 ， 了 解 哪些 元 素 已 经 遍历 过 而 哪些 
没有 。 迁 代 器 的 引入 ， 将 使 得 对 一 个 复杂 聚合 对 象 的 操作 变 得 简单 。 


下 面 我 们 结合 代码 来 对 迭代 器 模式 的 结构 进行 进一步 分 析 。 在 迭代 器 模式 中 应 用 了 工厂 方法 
模式 ， 抽 但 迭代 器 对 应 于 抽象 产品 角色 ， 具 体 迭 代 器 对 应 于 具体 产品 角色 ， 抽 但 聚合 类 对 应 
于 抽象 工厂 角色 ， 具 体 聚 合 类 对 应 于 具体 工厂 角色 。 


在 抽象 迭代 器 中 声明 了 用 于 遍历 聚合 对 象 中 所 存储 元 素 的 方法 ， 典 型 代码 如 下 所 示 : 


interface Iterator { 
public void first(); // 将 游标 指向 第 一 个 元 素 
public void next(); // 将 游标 指向 下 一 个 元 素 
public boolean hasNext(); // 判 断 是 否 存 在 下 一 个 元 素 
public Object currentItem( );， // 获 取 游 标 指向 的 当前 元 素 
} 


在 具体 选 代 器 中 将 实现 抽象 迭代 器 声明 的 遍历 数据 的 方法 ， 如 下 代码 所 示 : 


class ConcreteIterator implements Iterator { 
private ConcreteAggregate objects; // 维 持 一 个 对 具体 聚合 对 象 的 引用 ， 以 人 
private int cursor; // 定 义 一 个 游标 ， 用 于 记录 当前 访问 位 置 
public ConcreteIterator(ConcreteAggregate objects) { 
this.objects=objects; 
} 


public void first() { ...... } 
public void next() { .,,，,， } 
public boolean hasNext() { ...... } 


public Object currentItem() { ....,, } 
} 


需要 注意 的 是 抽象 迁 代 器 接口 的 设计 非常 重要 ， 一 方面 需要 充分 满足 各 种 遍历 操作 的 要 求 ， 

尽量 为 各 种 遍历 方法 都 提供 声明 ， 另 一 方面 又 不 能 包含 太 多 方法 ， 接 口中 方法 太 多 将 给 子 类 

的 实现 带 来 麻烦 。 因 此 ， 可 以 考虑 使 用 抽象 关 来 设计 抽象 选 代 器 ， 在 抽象 类 中 为 每 一 个 方法 

提供 一 个 空 的 默认 实现 。 如 果 需 要 在 具体 迭代 器 中 为 聚合 对 象 增加 全 新 的 遍历 操作 ， 则 必须 

修改 抽象 移 代 器 和 具体 迭代 器 的 源 代码 ， 这 将 违反 “ 开 闭 原则 ”, 因此 在 设计 时 要 考虑 全 面 ， 吉 
免 之 后 修改 接口 。 
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聚合 类 用 于 存储 数据 并 负责 创建 选 代 器 对 象 ， 最 简单 的 抽象 聚合 类 代码 如 下 所 示 : 


Interface Aggregate { 
Iterator createIterator( ) ， 
} 


具体 聚合 类 作为 抽象 聚合 类 的 子 类 ， 一 方面 负责 存储 数据 ， 另 一 方面 实现 了 在 抽象 聚合 类 中 
声明 的 工厂 方法 createlterator()， 用 于 返回 一 个 与 该 具体 聚合 类 对 应 的 具体 迭代 器 对 象 ， 代 三 
如 下 所 示 : 


class ConcreteAggregate implements Aggregate { 


public Iterator createIterator() { 
return new ConcreteIterator(this); 


思考 


理解 迭代 器 模式 中 具体 聚合 类 与 具体 迭代 器 类 之 间 存 在 的 依赖 关系 和 关联 关系 。 
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人 


遍历 聚合 对 象 中 的 元 素 一 人 达 代 器 模式 (三 ) 
遍历 有 聚合 对 但 中 的 元 素 一 一 迭代 器 模式 (三 ) 


3 完整 解决 方案 


为 了 简化 AbstractObjectList 类 的 结构 ， 并 给 不 同 的 具体 数据 集合 类 提供 不 同 的 遍历 方式 ， 
Sunny 软 件 公司 人 发 人 员 使 用 迭代 器 模式 来 重 构 AbstractObjectList 类 的 设计 ， 重 构 之 后 的 销售 
管理 系统 数据 遍历 结构 如 图 4 所 示 : 





图 4 销售 管理 系统 数据 遍历 结构 图 
( 注 :为 了 简化 类 图 和 代码 ， 本 结构 图 中 只 提供 一 个 具体 聚合 类 和 具体 迭代 器 类 ) 


在 图 4 中 ，AbstractObjectList 充 当 抽 得 聚合 类 ，ProductList 充 当 具 体 聚 合 类 ，AbstractIterator 充 
当 抽 象 迭 代 器 ，ProductIterator 充 当 具 体 和 迭代 器 。 完 整 代码 如 下 所 示 : 


// 在 本 实例 中 ， 为 了 详细 说 明 自 定义 迭代 器 的 实现 过 程 ， 我 们 没有 使 用 JDK 中 内 置 的 迁 代 器 
Import java.util.*; 


>- 


// 抽 象 聚 合 类 
abstract class AbstractObjectList { 
protected List<Object> objects = new ArrayList<object>() ， 


public AbstractobjectList(List objects) { 
this.objects = objects,; 


} 


public void addobject(object obj) { 
this.objects.add(obj); 
} 
313 


遍历 聚合 对 象 中 的 元 素 一 和 迭代 器 模式 《三 ) 


public void removeObject(Object obj) { 
this.objects.remove(obj); 


} 


public List getObjects() { 
return this,.objects; 
} 


// 声 明 创建 迭代 器 对 象 的 抽象 工厂 方法 
public abstract AbstractIterator createIterator() 


} 


// 商 品 数据 类 : 具体 聚合 类 
class ProductList extends AbstractobjectList { 
public ProductList(List products) { 
super(products); 


// 实 现 创 建 迭 代 器 对 象 的 具体 工厂 方法 
public AbstractIterator createIterator() { 
return new ProductIterator(this); 


} 
} 


// 抽 象 和 迭代 器 

interface AbstractIterator { 
public void next(); // 移 至 下 一 个 元 素 
public boolean isLast(); // 判 断 是 否 为 最 后 一 个 元 素 
public void previous(); // 移 至 上 一 个 元 素 
public boolean isFirst(); // 判 断 是 否 为 第 一 个 元 素 
public Object getNextItem( )， // 获 取 下 一 个 元 素 
public Object getPreviousItem(); // 获 取 上 一 个 元 素 


} 


// 商 品 迭 代 器 : 具体 迭代 器 

class ProductIterator implements AbstractIterator { 
private ProductList productList; 
private List products ; 
private int cursor1i; // 定 义 一 个 游标 ， 用 于 记录 正 向 遍历 的 位 置 
private int cursor2; // 定 义 一 个 游标 ， 用 于 记录 逆向 遍历 的 位 置 


public ProductIterator(ProductList list) { 
this.productList = list,; 
this.products = 1ist.getObjects(); // 获 取 集 合 对 象 
cursor1 = 0; // 设 置 正 向 遍历 游标 的 初始 值 
cursor2 = products.size() -1; // 设 置 北向 遍历 游标 的 初始 值 
} 


public void next() { 
if(cursor1 < products.size()) { 
CUrSoOr1I++， 


} 
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} 
public boolean isLast() { 

return (cursor1 == products.size()); 
} 


public void previous() { 
if (cursor2 > -1) { 
CUrsor2--，; 


} 
} 
public boolean isFirst() { 
return (cursor2 == -1); 
} 


public Object getNextItem() { 
return products.get(cursor1); 


} 


public Object getPreviousItem() { 
return products.get(cursor2); 


} 
} 


编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 

List products = new ArrayList(); 
products.,add(" 倚 天 剑 ")， 
products.add(" 屠 龙 刀 ")， 
products.add(" 断 肠 草 ")， 
products .add(" 英 花 宝 典 " ) ; 
products ,add(" 四 十 二 章 经 " ) ; 


AbstractobjectList list; 
AbstractIterator Iterator 


list = new ProductList(products); // 创 建 聚 合 对 象 
iterator = list.createIterator();  // 创 建 迭代 器 对 象 


System.out.println(" 正 向 遍历 : ")，; 

while(!iterator.isLast()) { 
System.out.print(iterator.getNextIitem() + "»，"); 
iterator.next(); 

} 

System,out,printJln()， 

System,out,println("----------------------------- J 

System.out.printljn(" 逆 向 遍历 : ")， 

while(!iterator.isFirst()) { 
System.out.print(iterator.getPreviousIitem() + "»"); 
iterator .previous(); 
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} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


正 向 遍历 : 
倚天 剑 ， 层 龙 刀 ， 断 肠 草 ， 英 花 宝 典 ， 四 十 二 章 经 ， 


如 果 需 要 增加 一 个 新 的 具体 聚合 类 ， 如 客户 数据 集合 类 ， 并 且 需 要 为 客户 数据 集合 类 提供 不 
同 于 商品 数据 集合 类 的 正 向 遍历 和 逆向 遍历 操作 ， 只 需 增 加 一 个 新 的 聚合 子 类 和 一 个 新 的 具 
体 迭 代 器 类 即 可 ， 原 有 类 库 代码 无 须 修改 ， 符 合 “ 开 闭 原则 ”; 如 果 需 要 为 ProductList 类 更 换 一 
个 迭代 器 ， 只 需要 增加 一 个 新 的 具体 和 迭代 器 类 作为 抽象 迭代 器 类 的 子 类 ， 重 新 实现 遍历 方 
法 ， 原 有 迁 代 器 代码 无 须 修 改 ， 也 符合 *“ 开 闭 原则 ”; 但 是 如 果 要 在 迭代 器 中 增加 新 的 方法 ， 则 
需要 修改 抽象 迭代 器 源 代码 ， 这 将 违背 “ 开 闭 原则 ”。 
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遍历 聚合 对 象 中 的 元 素 - 迭代 器 模式 (四 ) 
遍历 聚合 对 象 中 的 元 素 - 迭代 器 模式 (四 ) 


4 使 用 内 部 类 实现 迭代 器 


在 迭代 器 模式 结构 图 中 ， 我 们 可 以 看 到 具体 迭代 器 类 和 具体 聚合 类 之 间 存 在 双重 关系 ， 其 中 
一 个 关系 为 关联 关系 ， 在 具体 迭代 器 中 需要 维持 一 个 对 具体 聚合 对 象 的 引用 ， 该 关联 关系 的 
目的 是 访问 存储 在 聚合 对 象 中 的 数据 ， 以 便 和 迭代 器 能 够 对 这 些 数据 进行 遍历 操作 。 


除了 使 用 关联 关系 外 ， 为 了 能 够 让 和 迭代 器 可 以 访问 到 聚合 对 象 中 的 数据 ， 我 们 还 可 以 将 迭代 
器 类 设计 为 聚合 类 的 内 部 类 ，JDK 中 的 迭代 器 类 就 是 通过 这 种 方法 来 实现 的 ， 如 下 AbstractL ist 
类 代码 片段 所 示 : 


package java.util; 


private class Itr implements Iterator<E> { 
int cursor = 0; 


我 们 可 以 通过 类 似 的 方法 来 设计 第 3 节 中 的 ProductList 类 ， 将 ProductIterator 类 作为 ProductList 类 
的 内 部 类 ， 代 码 如 下 所 示 : 


// 商 品 数据 类 : 具体 聚合 类 
class ProductList extends AbstractobjectList { 
public ProductList(List products) { 
super(products); 


public AbstractIterator createIterator() { 
return new ProductIterator(); 


} 


// 商 品 迭 代 器 : 具体 迭代 器 ， 内 部 类 实现 

private class ProductIterator implements AbstractIterator { 
private int cursori1; 
private int cursor2,; 


public ProductIterator() { 
cursor1 = 0; 
cursor2 = objects.size() -1; 


} 


public void next() { 
if(cursor1 < objects.size()) { 


317 


遍历 聚合 对 象 中 的 元 素 一 和 迭代 器 模式 《四 ) 


CUrSoOr1I++， 
} 
} 
public boolean isLast() { 
return (cursor1 == objects.size()); 
} 


public void previous() { 
if(cursor2 > -1) { 
cursor2--，; 


} 
} 
public boolean isFirst() { 
return (cursor2 == -1); 
} 


public Object getNextItem() { 
return objects.get(cursor1); 
} 


public Object getPreviousItem() { 
return objects.get(cursor2); 
} 


} 
无 论 使 用 哪 种 实现 机 制 ， 客 户 端 代码 都 是 一 样 的 ， 也 就 是 说 客户 端 无 须 关 心 具体 迭代 器 对 象 


的 创建 细节 ， 只 需 通过 调用 工厂 方法 createIterator() 即 可 得 到 一 个 可 用 的 迭代 器 对 象 ， 这 也 是 
使 用 工厂 方法 模式 的 好 处 ， 通 过 工厂 来 封装 对 象 的 创建 过 程 ， 简 化 了 客户 端的 调用 。 
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遍历 聚合 对 象 中 的 元 素 _ 迭代 器 模式 (五 ) 
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5JDK 内 置 和 迭代 器 


为 了 让 开发 人 员 能 够 更 加 方便 地 操作 聚合 对 象 ， 在 Java、C# 等 编程 语言 中 都 提供 了 内 置 迁 代 
器 。 在 Java 集 合 框架 中 ， 常 用 的 List 和 Set 等 聚合 类 都 继承 (或 实现 ) 了 java.util.Collection 接 
口 ， 在 Collection 接 口中 声明 了 如 下 方法 (部 分 ) 


package java.util; 


public interface Collection<E> extends Iterable<E> { 
boolean add(Object c); 

boolean addAll(Collection c); 

boolean remove(Object 0o); 

boolean removeAll(Collection c); 

boolean remainAll(Collection c); 

Iterator iterator(); 


除了 包含 一 些 增 加 元 素 和 删除 元 素 的 方法 外 ， 还 提供 了 一 个 iterator() 方 法 ， 用 于 返回 一 个 
Iterator 和 迭代 器 对 象 ， 以 便 遍 历 聚 合 中 的 元 素 ; 具体 的 Java 有 聚合 类 可 以 通过 实现 该 iterator() 方 法 
返回 一 个 具体 的 Iterator 对 象 。 


JDK 中 定义 了 抽象 迭代 器 接口 Iterator， 代 码 如 下 所 示 : 
package java.util,; 


public interface Iterator<E> { 
boolean hasNext(); 

E next(); 

void remove( ) ; 


} 


其 中 ，hasNext() 用 于 判断 聚合 对 象 中 是 否 还 存在 下 一 个 元 素 ， 为 了 不 抛 出 异常 ， 在 每 次 调用 

next(0 之 前 需 先 调用 hasNext()， 如 果 有 可 供 访问 的 元 素 ， 则 返回 true ; next() 方 法 用 于 将 游标 移 
至 下 一 个 元 素 ， 通 过 它 可 以 逐个 访问 聚合 中 的 元 素 ， 它 返回 游标 所 越过 的 那个 元 素 的 引用 ; 

remove() 方 法 用 于 删除 上 次 调用 next() 时 所 返回 的 元 素 。 


Java 迄 代 器 工作 原理 如 图 5 所 示 ， 在 第 一 个 next() 方 法 被 调用 时 ， 和 迭代 器 游标 由 “元 素 1” 与 “元 素 
2” 之 间 移 至 “元 素 2” 与 “元 素 3” 之 间 ， 跨 越 了 “元 素 2”， 因 此 next() 方 法 将 返回 对 “元 素 2” 的 引用 ; 
在 第 二 个 next(0) 方 法 被 调用 时 ， 先 代 器 由 “元 素 2” 与 “元 素 3” 之 间 移 至 “元 素 3" 和 "元素 4" 之 问 ， 
next() 方 法 将 返回 对 “元 素 3” 的 引用 ， 如 果 此 时 调用 remove() 方 法 ， 即 可 将 “元 素 3” 删 除 。 
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next()+ remove(): 





图 5 Java 和 迭代 器 示意 图 
如 下 代码 片段 可 用 于 删除 聚合 对 象 中 的 第 一 个 元 素 : 


Iterator iterator = collection.iterator(); //collection 是 已 实例 化 的 肥 
iterator.next(); // 跳 过 第 一 个 元 素 
iterator .remove();， // 删除 第 一 个 元 素 


需要 注意 的 是 ， 在 这 里 ，next() 方 法 与 remove() 方 法 的 调用 是 相互 关联 的 。 如 果 调 用 remove() 之 
前 ， 没 有 先 对 nextO 进 行 调用 ， 那 么 将 会 抛 出 一 个 lllegalStateException 异 常 ， 因 为 没有 任何 可 
供 删 除 的 元 素 。 如 下 代码 片段 可 用 于 删除 两 个 相 邻 的 元 素 : 


Iterator ,remove( ); 
iterator ,next(); // 如 果 删 除 此 行 代码 程序 将 抛 异 常 
iterator.remove( ); 


在 上 面 的 代码 片段 中 如 果 将 代码 iterator.next(); 去 掉 则 程序 运行 抛 异 常 ， 因 为 第 二 次 删除 时 将 找 
不 到 可 供 删 除 的 元 素 。 


在 JDK 中 ，Collection 接 口 和 Iterator 接 口 充 当 了 和 迭代 器 模式 的 抽象 层 ， 分 别 对 应 于 抽象 聚合 类 和 
抽象 迭 代 器 ， 而 Collection 接 口 的 子 类 充当 了 具体 聚合 类 ， 下 面 以 List 为 例 加 以 说 明 ， 图 6 列 出 
了 JDK 中 部 分 与 List 有 关 的 类 及 它们 之 间 的 关系 : 


















有 Collection ”IErator 
+ iterator () : lterator | 
A 苹 





~ Listlterator 


~ 


lterator 
: Listiterator 











AbstractSequentialList 


























AbstractList 
LinkedList 
+ erator 0 -erator |-nieratoro | 
+ listlterator () - Listlterator + listiterator (int index) : Listiterator + listlterator (int index) : Listlterator 


+ listlterator (int index) : Listlterator 





图 6 Java 集 合 框架 中 部 分 类 结构 图 
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( 注 :为 了 简化 类 图 ， 本 图 省 略 了 大 量 方法 ) 
在 JDK 中 ， 实 际 情况 比 图 6 要 复杂 很 多 ， 在 图 6 中 ，List 接 口 除 了 继承 Collection 接 口 的 iterator() 
方法 外 ， 还 增加 了 新 的 工厂 方法 listIterator()， 专 门 用 于 创建 ListIterator 类 型 的 迭代 器 ， 在 List 的 
子 类 LinkedList 中 实现 了 该 方法 ， 可 用 于 创建 具体 的 ListIterator 子 类 ListItr 的 对 象 ， 代 码 如 下 所 
示 : 


public ListIterator<E> listIiterator(int index) { 
return new ListItr(index); 


} 
listIterator() 方 法 用 于 返回 具体 迭代 器 ListItr 类 型 的 对 象 。 在 JDK 源 码 中 ，Abstract 


public Iterator iterator() { 
return listIterator(); 


} 
客户 端 通过 调用 LinkedList 类 的 iterator() 方 法 ， 即 可 得 到 一 个 专门 用 于 遍历 LinkedLi 
大 家 可 能 会 问 ? 既然 有 了 iterator() 方 法 ， 为 什么 还 要 提供 一 个 ListIterator() 方 法 呢 


这 是 一 个 好 问题 。 我 给 大 家 简单 解释 一 下 为 什么 要 这 样 设 计 : 由 于 在 Iterator 接 口中 定义 的 


ListIterator i = c.listIterator(); 


正 因为 如 此 ， 在 JDK 的 List 接 口中 不 得 不 增加 对 1]istIterator() 方 法 的 声明 ， 该 方法 可 以 3 
思考 

为 什么 使 用 iterator( ) 方 法 创建 的 迭代 器 无 法 实现 逆向 遍 

在 Java 语 言 中 ， 我 们 可 以 直接 使 用 JDK 内 置 的 迭代 器 来 遍历 聚合 对 象 中 的 元 素 ， 下 面 的 代码 演 
import java.util.*; 


class IteratorDemo { 
public static void process(Collection c) { 
Iterator i = Cc.iterator(); /创建 迭代 器 对 象 


// 通 过 和 迭代 器 遍历 聚合 对 象 

while(i.hasNext()) { 
System,.out.printlin(i.next().toString()); 

} 


} 


public static void main(String args[]) { 
Collection persons ; 


persons = new ArrayList(); /创建 一 个 ArrayList 类 型 的 聚合 对 象 
persons.add(" 张 无 总"); 
persons.add(" 小 龙 女 "); 
persons.add(" 令 狐 冲 "); 
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persons.add(" 韦 小 宝 "); 
persons.add(" 训 紫衣 "); 
persons.add(" 小 龙 女 "); 


process(persons); 


} 
} 
在 静态 方法 process( ) 中 使 用 迭代 器 Iterator 对 Collection 对 象 进行 处 理 ， 该 代码 运行 


张无忌 小 龙 女 令狐冲 韦小宝 表 兹 衣 小 龙 女 


如 果 需 要 更 换 聚 合 类 型 ， 如 将 List 改 成 Set， 则 只 需 更 换 具体 聚合 类 类 名 ， 如 将 上 述 代码 中 鲜 
令狐冲 张无忌 韦小宝 小 龙 女 袁 紫 衣 、 
在 HashSet 中 合并 了 重复 元 素 ， 并 且 元 素 以 随机 次 序 输出 ， 其 结果 与 使 用 ArrayList 不 相同 。 由 
此 可 见 ， 通 过 使 用 迭代 器 模式 ， 使 得 更 换 具 体 聚 合 类 变 得 非常 方便 ， 而 且 还 可 以 根据 需要 增 
加 新 的 聚合 类 ， 新 的 聚合 类 只 需要 实现 Collection 接 口 ， 无 须 修 改 原 有 类 库 代 码 ， 符 合 “ 开 闭 原 
则 ”。 
练习 

在 Sunny 软 件 公司 开发 的 某 教务 管理 系统 中 ， 一 个 班级 (Class in School) 包 含 多 个 学 生 


(StudenbD， 使 用 Java 内 置 和 迭代 器 实现 对 学 生 信 息 的 遍历 ， 要 求 按 学 生年 瞧 | 小 的 次 序 
输 出 学 生 信 息 2 
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遍历 聚合 对 和 象 中 的 元 素 一 一 和 迭代 问 模 式 〈 六 ) 
遍历 聚合 对 象 中 的 元 率 一 一 和 迭代 器 模式 《六 ) 


6 和 迭代 器 模式 总 结 


和 迭代 器 模式 是 一 种 使 用 频率 非常 高 的 设计 模式 ， 通 过 引入 和 迭代 器 可 以 将 数据 的 遍历 功能 从 聚 
合 对 象 中 分 离 出 来 ， 聚 合 对 象 只 负责 存储 数据 ， 而 遍历 数据 由 和 迭代 器 来 完成 。 由 于 很 多 编程 
语言 的 类 库 都 已 经 实现 了 和 迭代 器 模式 ， 因此 在 实际 开发 中 ， 我 们 只 需要 直接 使 用 Java、C# 等 
语言 已 定义 好 的 和 迭代 器 即 可 ， 和 迭 代 器 已 经 成 为 我 们 操作 聚合 对 象 的 基本 工具 之 一 。 
1. 主要 优点 
和 迭代 器 模式 的 主要 优点 如 下 : 
(1) 它 支持 以 不 同 的 方式 遍历 一 个 聚合 对 象 ， 在 同一 个 聚合 对 象 上 可 以 定义 多 种 遍历 方 
式 。 在 迭代 器 模式 中 只 需要 用 一 个 不 同 的 迭代 器 来 替换 原 有 迭代 器 即 可 改变 遍历 算法 ， 
我 们 也 可 以 自己 定义 迭代 器 的 子 类 以 支持 新 的 遍历 方式 。 


(2) 近代 器 简化 了 聚合 类 。 由 于 引入 了 选 代 器 ， 在 原 有 的 聚合 对 象 中 不 需要 再 自行 提供 数据 遍 
历 等 方法 ， 这 样 可 以 简化 聚合 类 的 设计 。 


(3) 在 迭代 器 模式 中 ， 由 于 引入 了 抽象 层 ， 增 加 新 的 聚合 类 和 壕 代 器 类 都 很 方便 ， 无 须 修改 原 
有 代码 ， 满 足 “ 开 闭 原则 ”的 要 求 。 


1. 主要 缺点 
迭代 器 模式 的 主要 缺点 如 下 : 


(1) 由 于 选 代 器 模式 将 存储 数据 和 遍历 数据 的 职责 分 离 ， 增 加 新 的 聚合 类 需要 对 应 增加 新 的 先 
代 器 类 ， 类 的 个 数 成 对 增加 ， 这 在 一 定 程度 上 增加 了 系统 的 复杂 性 。 


(2) 抽象 迭代 器 的 设计 难度 较 大 ， 需 要 充分 考虑 到 系统 将 来 的 扩展 ， 例 如 JDK 内 置 和 迭代 器 
Iterator 就 无 法 实现 逆向 遍历 ， 如 果 需 要 实现 逆向 遍历 ， 只 能 通过 其 子 类 ListIterator 等 来 实现 ， 


而 ListIterator 和 迭代 器 无 法 用 于 操作 Set 类 型 的 聚合 对 象 。 在 自 定义 和 迭代 器 时 ， 创 建 一 个 考虑 全 面 
的 抽象 迭代 器 并 不 是 件 很 容易 的 事情 。 


适用 场景 
在 以 下 ' 博 况 下 可 以 考虑 使 用 迭代 器 模式 : 


(1) 访问 一 个 聚合 对 象 的 内 容 而 无 须 暴露 它 的 内 部 表示 。 将 聚合 对 象 的 访问 与 内 部 数据 的 存储 
分 离 ， 使 得 访问 聚合 对 象 时 无 须 了 解 其 内 部 实现 细节 。 


(2) 需要 为 一 个 聚合 对 象 提 供 多 种 遍历 方式 。 


(3) 为 遍历 不 同 的 聚合 结构 提供 一 个 统一 的 接口 ， 在 该 接口 的 实现 类 中 为 不 同 的 聚合 结构 提供 
不 同 的 遍历 方式 ， 而 客户 端 可 以 一 致 性 地 操作 该 接口 。 


练习 
设计 一 个 逐 页 迭代 器 ， 每 次 可 返回 指定 个 数 (一 页 ) 元 素 ， 并 将 该 先 代 器 用 于 对 数据 进 
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~ 


处 理 。 


my 
心 
党 
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中 介 者 模式 -Mediator Pattern 
中 介 者 模式 -Mediator Pattern 


中 介 者 模式 -Mediator Pattern 【学 习 难 度 : 真 友 龙 六 衣 ， 使 用 频率 : 丰 丰 六 六 六 】 


e@ 中 介 者 模式 -Mediator Pattern 
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o 协调 多 个 对 象 之 间 的 交互 一 中 介 者 模式 (五 
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协调 多 个 对 象 之 间 的 交互 一 中介 者 模式 
Ge 


协调 乡 个 对 象 之 间 的 交互 一 一 中 介 者 模式 
Sn 


腾讯 公司 推出 的 QQ 作为 一 款 免费 的 即时 聊天 软件 深 受 广大 用 户 的 喜爱 ， 它 已 经 成 为 很 多 人 学 
习 、 工 作 和 生活 的 一 部 分 (不 要 告诉 我 你 没有 QQ 哦 ) 。 在 QQ 聊天 中 ， 一 般 有 两 种 聊天 方式 : 
第 一 种 是 用 户 与 用 户 直 接 聊 天 ， 第 二 种 是 通过 QQ 群 聊天 ， 如 图 20-1 所 示 。 如 果 我 们 使 用 图 20- 
1(A) 所 示 方 式 ， 一 个 用 户 如 果 要 与 别 的 用 户 聊天 或 发 送 文件 ， 通 常 需要 加 其 他 用 户 为 好 友 ， 用 
户 与 用 户 之 间 存 在 多 对 多 的 联系 ， 这 将 导致 系统 中 用 户 之 间 的 关系 非常 复杂 ， 一 个 用 户 如 果 
要 将 相同 的 信息 或 文件 发 送 给 其 他 所 有 用 户 ， 必 须 一 个 一 个 的 发 送 ， 于 是 QQ 群 产 生 了 ， 如 图 
20-1(B) 所 示 ， 如 果 使 用 QQ 群 ， 一 个 用 户 就 可 以 向 多 个 用 户 发 送 相 同 的 信息 和 文件 而 无 须 一 一 
进行 发 送 ， 只 需要 将 信息 或 文件 发 送 到 群 中 或 作为 群 共 享 即 可 ， 群 的 作用 就 是 将 发 送 者 所 发 
送 的 信息 和 文件 转发 给 每 一 个 接收 者 用 户 。 通 过 引入 群 的 机 制 ， 将 极 大 减少 系统 中 用 户 之 间 
的 两 两 通信 ， 用 户 与 用 户 之 间 的 联系 可 以 通过 群 来 实现 。 






9 WN 0 pe 
A 
交 淡 中 请 勿 既 信 汇款 、 中 奖 信息 、 隔 生 电话 ， 勿 使 用 外 挂 软件 . 时 动 记 








,| 界 
2 双 
1 3 

证 


和 已 路 | 回 过 园 . 回 | 吕 - 国 ji 好- 


(A) (B) 
图 20-1 QQ 聊天 示意 图 
在 有 些 软件 中 ， 某 些 类 /对 象 之 间 的 相互 调用 关系 错综复杂 ， 类 似 QQ 用 户 之 间 的 关系 ， 此 时 ， 
我 们 特别 需要 一 个 类 似 “QQ 群 "一样 的 中 间 类 来 协调 这 些 类 /对 象 之 间 的 复杂 关系 ， 以 降低 系统 
的 耦合 度 。 有 一 个 设计 模式 正 为 此 而 诞生 ， 它 就 是 本 章 将 要 介绍 的 中 介 者 模式 。 
20.1 客户 信息 管理 窗口 的 初始 设计 


Sunny 软 件 公司 欲 开发 一 套 CRM 系 统 ， 其 中 包含 一 个 客户 信息 管理 模块 ， 所 设计 的 “客户 信息 
管理 窗口 ?界面 效果 图 如 图 20-2 所 示 : 
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客户 信息 井 理 徐 日 


客户 信 忆 管 理 


请 输入 查询 关键 字 : 








姓名 : 
性 别 : ”名 男 O 妇 
出 生日 期 : 1980 年 [10 


联系 电话 : 113000001111 





电子 邮箱 : | wujl_zhang(@dp.com 





图 20-2 “客户 信息 管理 窗口 "界面 图 

Sunny 公 司 开发 人 员 通 过 分 析 发 现 ， 在 图 20-2 中 ， 界 面 组 件 之 间 存 在 较为 复杂 的 交互 关系 : 如 
果 删 除 一 个 客户 ， 要 在 客户 列表 (List) 中 删 掉 对 应 的 项 ， 客 户 选择 组 合 框 (ComboBox) 中 客户 名 
称 也 将 减少 一 个 ; 如 果 增 加 一 个 客户 信息 ， 客 户 列 表 中 需 增 加 一 个 客户 ， 且 组 合 框 中 也 将 增 
加 一 项 o 

如 果实 现 界面 组 件 之 间 的 交互 是 Sunny 公 司 开 发 人 员 必 须 面 对 的 一 个 问题 ? 

Sunny 公 司 开 发 人 员 对 组 件 之 间 的 交互 关系 进行 了 分 析 ， 结 果 如 下 : 


(1) 当 用 户 单 击 “ 增 加 ”按钮 、“ 删 除 ” 按 钮 “修改” 按钮 或 “查询 ”按钮 时 ， 界 面 左 侧 的 “客户 选择 
组 合 框 ?、“ 客 户 列表 ”以 及 界面 中 的 文本 框 将 产生 响应 。 


(2) 当 用 户 通 过 “客户 选择 组 合 框 ”选中 某 个 客户 姓名 时 ，“ 客 户 列表 ”和 文本 框 将 产生 响应 。 
(3) 当 用 户 通过 “客户 列表 ”选中 某 个 客户 姓名 时 ，“ 客 户 选择 组 合 框 "和 文本 框 将 产生 响应 。 
于 是 ，Sunny 公 司 开发 人 员 根 据 组 件 之 间 的 交互 关系 绘制 了 如 图 20-3 所 示 初 始 类 图 : 
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图 20-3 “客户 信息 管理 窗口 "原始 类 图 
与 类 图 20-3 所 对 应 的 框架 代码 片段 如 下 : 


// 按 钮 类 

class Button { 
private List list; 
private ComboBox cb 
private TextBox tb; 


// 界 面 组 件 的 交互 

public void change() { 
list.update(); 
cb.update( ); 
tb.update( ); 


} 
public void update() { 
ee 

ee 

// 列 表 框 类 


class List { 
private ComboBox cb 
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private TextBox tb 


// 界 面 组 件 的 交互 
public void change() { 
cb.update( ); 
tb.update( ); 


} 
public void update() { 
a 

ge Sp 

// 组 合 框 类 


class ComboBox { 
private List list,; 
private TextBox tb; 


// 界 面 组 件 的 交互 
public void change() { 
list.update( ); 
tb.update( ); 


} 
public void update() { 
a 

es 

// 文 本 框 类 


class TextBox { 
public void update() { 


分 析 图 20-3 所 示 初 始 结构 图 和 上 述 代码 ， 我 们 不 难 发 现 该 设计 方案 存在 如 下 问题 : 


(1) 系统 结构 复杂 且 耦 合 度 高 : 每 一 个 界面 组 件 都 与 多 个 其 他 组 件 之 间 产 生 相 互 关联 和 调用 ， 
若 一 个 界面 组 件 对 象 发 生变 化 ， 需 要 跟踪 与 之 有 关联 的 其 他 所 有 组 件 并 进行 处 理 ， 系 统 组 件 
之 间 呈 现 一 种 较为 复杂 的 网 状 结构 ， 组 件 之 间 的 耦合 度 高 。 


(2) 组 件 的 可 重用 性 差 : 由 于 每 一 个 组 件 和 其 他 组 件 之 问 都 具有 很 强 的 关联 ， 若 没有 其 他 组 件 
的 支持 ， 一 个 组 件 很 难 被 另 一 个 系统 或 模块 重用 ， 这 些 组 件 表现 出 来 更 像 一 个 不 可 分 割 的 整 
体 ， 而 在 实际 使 用 时 ， 我 们 往往 需要 每 一 个 组 件 都 能 够 单独 重用 ， 而 不 是 重用 一 个 由 多 个 组 
件 组 成 的 复杂 结构 。 


(3) 系统 的 可 扩展 性 差 : 如 果 在 上 述 系 统 中 增加 一 个 新 的 组 件 类 ， 则 必须 修改 与 之 交互 的 其 他 
组 件 类 的 源 代 码 ， 将 导致 多 个 类 的 源 代 码 需要 修改 ， 同 样 ， 如 果 要 删除 一 个 组 件 也 存在 类 似 
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的 问题 ， 这 违反 了 “ 开 闭 原则 ”， 可 扩展 性 和 灵活 性 欠 佳 。 


由 于 存在 上 述 问题 ，Sunny 公 司 开发 人 员 不 得 不 对 原 有 系统 进行 重 构 ， 那 如 何 重 构 呢 ? 大 
家 想到 了 “ 迪 米 特 法 则 ”， 引 入 一 个 “第 三 者 ”来 降低 现 有 系统 中 类 之 间 的 看 合 度 。 由 这 
个 “第 三 者 "来 封装 并 协调 原 有 组 件 两 两 之 间 复 杂 的 引用 关系 ， 使 之 成 为 一 个 松 耦 合 的 系 
统 ， 这 个 “第 三 者 "又 称 为 “中介 者 "”， 中 介 者 模式 因此 而 得 名 。 下 面 让 我 们 正式 进入 中 介 者 
模式 的 学 习 ， 学 会 如 何 使 用 中 介 者 类 来 协调 多 个 类 /对 象 之 间 的 交互 ， 以 达到 降低 系统 耦 
合 度 的 目的 。 
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个 对 象 之 间 的 交互 -中介 者 模式 


个 对 象 之 间 的 交互 一 一 中 介 者 模式 


20.2 中 介 者 模式 概述 


如 果 在 一 个 系统 中 对 象 之 间 的 联系 呈现 为 网 状 结构 ， 如 图 20-4 所 示 。 对 象 之 间 存 在 大 量 的 多 对 
多 联系 ， 将 导致 系统 非常 复杂 ， 这 些 对 象 既 会 影响 别 的 对 象 ， 也 会 被 别 的 对 象 所 影响 ， 这 些 
对 象 称 为 同事 对 象 ， 它 们 之 间 通 过 彼此 的 相互 作用 实现 系统 的 行为 。 在 网 状 结构 中 ， 几 乎 每 
个 对 象 都 需要 与 其 他 对 象 发 生 相 互 作 用 ， 而 这 种 相互 作用 表现 为 一 个 对 象 与 另外 一 个 对 象 的 
直接 看 合 ， 这 将 导致 一 个 过 度 耦 合 的 系统 。 





图 20-4 对 象 之 间 存 在 复杂 关系 的 网 状 结构 


中 介 者 模式 可 以 使 对 象 之 间 的 关系 数量 急剧 减少 ， 通 过 引入 中 介 者 对 象 ， 可 以 将 系统 的 网 状 
结构 变 成 以 中 介 者 为 中 心 的 星 形 结构 ， 如 图 20-5 所 示 。 在 这 个 星 形 结构 中 ， 同 事 对 象 不 再 直接 
与 另 一 个 对 象 联系 ， 它 通过 中 介 者 对 象 与 另 一 个 对 象 发 生 相 互 作 用 。 中 介 者 对 象 的 存在 保证 
了 对 象 结 构 上 的 稳定 ， 也 就 是 说 ， 系 统 的 结构 不 会 因为 新 对 象 的 引入 带 来 大 量 的 修改 工作 。 
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图 20-5 引入 中 介 者 对 象 的 星 型 结构 


如 果 在 一 个 系统 中 对 象 之 问 存 在 多 对 多 的 相互 关系 ， 我 们 可 以 将 对 象 之 间 的 一 些 交互 行为 从 
各 个 对 象 中 分 离 出 来 ， 并 集中 封装 在 一 个 中 介 者 对 象 中 ， 并 由 该 中 介 者 进行 统一 协调 ， 这 样 
对 象 之 间 多 对 多 的 复杂 关系 就 转化 为 相对 简单 的 一 对 多 关系 。 通 过 引入 中 介 者 来 简化 对 象 之 
间 的 复杂 交互 ， 中介 者 模式 是 “ 迪 米 特 法 则 ”的 一 个 典型 应 用 。 


中 介 者 模式 定义 如 下 : 
中 介 者 模式 (Mediator Pattern) : 用 一 个 中 介 对 象 〈 中 介 者 ) 来 封装 一 系列 的 对 象 交 互 ， 中 
介 者 使 各 对 象 不 需要 显 式 地 相互 引用 ， 从 而 使 其 耦合 松散 ， 而 且 可 以 独立 地 改变 它们 之 
间 的 交互 。 中 介 者 模式 又 称 为 调停 者 模式 ， 它 是 一 种 对 象 行为 型 模式 。 


在 中 介 者 模式 中 ， 我 们 引入 了 用 于 协调 其 他 对 象 /类 之 间 相 互 调用 的 中 介 者 类 ， 为 了 让 系统 具 
有 更 好 的 灵活 性 和 可 扩展 性 ， 通 常 还 提供 了 抽象 中 介 者 ， 其 结构 图 如 图 20-6 所 示 : 











| Colleague 











Mediator 





mediator 









ConcreteMediator 


ConcreteColleagueA 







ConcreteColleagueB 








图 20-6 中 介 者 模式 结构 图 
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在 中 介 者 模式 结构 图 中 包含 如 下 几 个 角色 : 
e Mediator (抽象 中 介 者 ) : 它 定 义 一 个 接口 ， 该 接口 用 于 与 各 同事 对 象 之 间 进 行 通信 。 


e@ ConcreteMediator (具体 中 介 者 ) : 它 是 抽象 中 介 者 的 子 类 ， 通 过 协调 各 个 同事 对 象 来 实现 
协作 行为 ， 它 维持 了 对 各 个 同事 对 象 的 引用 。 


e@ Colleague (抽象 同事 类 ) : 它 定义 各 个 同事 类 公有 的 方法 ， 并 声明 了 一 些 抽象 方法 来 供 子 类 
实现 ， 同 时 它 维持 了 一 个 对 抽象 中 介 者 类 的 引用 ， 其 子 类 可 以 通过 该 引用 来 与 中 介 者 通信 。 


e ConcreteColleague (具体 同事 类 ) : 它 是 抽象 同事 类 的 子 类 ; 每 一 个 同事 对 象 在 需要 和 其 他 
同事 对 象 通信 时 ， 先 与 中 介 者 通信 ， 通 过 中 介 者 来 间接 完成 与 其 他 同事 类 的 通信 ; 在 具体 同 
事 类 中 实现 了 在 抽象 同事 类 中 声明 的 抽象 方法 。 


中 介 者 模式 的 核心 在 于 中 介 者 类 的 引入 ， 在 中 介 者 模式 中 ， 中 介 者 类 承担 了 两 方面 的 职责 : 


(1) 中 转 作用 (结构 性 ) : 通过 中 介 者 提供 的 中 转 作 用 ， 各 个 同事 对 象 就 不 再 需要 显 式 引用 其 
他 同事 ， 当 需要 和 其 他 同事 进行 通信 时 ， 可 通过 中 介 者 来 实现 间接 调用 。 该 中 转 作用 属于 中 
介 者 在 结构 上 的 支持 。(2) 协调 作用 (行为 性 ) : 中 介 者 可 以 更 进一步 的 对 同事 之 间 的 关系 进 
行 封装 ， 同 事 可 以 一 致 的 和 中 介 者 进行 交互 ， 而 不 需要 指明 中 介 者 需要 具体 怎么 做 ， 中 介 者 
根据 封装 在 自身 内 部 的 协调 逻辑 ， 对 同事 的 请 求 进行 进一步 处 理 ， 将 同事 成 员 之 间 的 关系 行 
为 进行 分 离 和 封装 。 该 协调 作用 属于 中 介 者 在 行为 上 的 支持 。 


在 中 介 者 模式 中 ， 典 型 的 抽象 中 介 者 类 代码 如 下 所 示 : 


abstract class Mediator { 
protected ArrayList<Colleague> colleagues; // 用 于 存储 同事 对 象 


// 注 册 方 法 ， 用 于 增加 同事 对 象 

public void register(Colleague colleague) { 
colleagues.add(colleague); 

} 


// 声 明 抽 象 的 业务 方法 
public abstract void operation(); 


在 抽象 中 介 者 中 可 以 定义 一 个 同事 类 的 集合 ， 用 于 存储 同事 对 象 并 提供 注册 方法 ， 同 
[java] view plain copy 
class ConcreteMediator extends Mediator { 
// 实 现 业 务 方法 ， 封 装 同事 之 问 的 调用 
public void operation() { 


在 具体 中 介 者 类 中 将 调用 同事 类 的 方法 ， 调 用 时 可 以 增加 一 些 自己 的 业务 代码 对 调用 进行 控 
制 。 


在 抽象 同事 类 中 维持 了 一 个 抽象 中 介 者 的 引用 ， 用 于 调用 中 介 者 的 方法 ， 典 型 的 抽象 同事 类 
代码 如 下 所 示 : 


abstract class Colleague { 
protected Mediator mediator; // 维 持 一 个 抽象 中 介 者 的 引用 
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public Colleague(Mediator mediator) { 
this.mediator=mediator; 
} 


public abstract void methodi(); // 声 明 自 身 方法 ， 处 理 自己 的 行为 


// 定 义 依赖 方法 ， 与 中 介 者 进行 通信 

public void method2() { 
mediator .operation(); 

} 


} 


在 抽象 同事 类 中 声明 了 同事 类 的 抽象 方法 ， 而 在 具体 同事 类 中 将 实现 这 些 方法 ， 典 型 的 具体 
同事 类 代码 如 下 所 示 : 
class ConcreteColleague extends Colleague { 


public ConcreteColleague(Mediator mediator) { 
super (mediator ); 


// 实 现 自身 方法 
public void method1() { 


人 
} 


在 具体 同事 类 ConcreteColleague 中 实现 了 在 抽象 同事 类 中 声明 的 方法 ， 其 中 方法 method10 是 同 
事 类 的 自身 方法 (Self-Method)， 用 于 处 理 自己 的 行为 ， 而 方法 method2() 是 依赖 方法 (Depend- 

Method)， 用 于 调用 在 中 介 者 中 定义 的 方法 ， 依 赖 中 介 者 来 完成 相应 的 行为 ， 例 如 调用 另 一 个 
同事 类 的 相关 方法 。 


加 
心 


如 何 理解 同事 类 中 的 自身 方法 与 依赖 方法 ? 


334 


协调 多 个 对 得 之 间 的 交互 一 一 中 介 者 模式 (三 ) 


个 对 象 之 间 的 交互 一 一 中 介 者 模式 


个 对 象 之 间 的 交互 一 一 中 介 者 模式 


20.3 完整 解决 方案 


为 了 协调 界面 组 件 对 象 之 间 的 复杂 交互 关系 ，Sunny 公 司 开发 人 员 使 用 中 介 者 模式 来 设计 客户 
信息 管理 窗口 ， 其 结构 示意 图 如 图 20-7 所 示 : 





图 20-7 引入 了 中 介 者 类 的 “客户 信息 管理 窗口 ”结构 示意 图 
图 20-7 只 是 一 个 重 构 之 后 的 结构 示意 图 ， 在 具体 实现 时 ， 为 了 确保 系统 具有 更 好 的 灵活 性 和 可 


扩展 性 ， 我 们 需要 定义 抽象 中 介 者 和 抽象 组 件 类 ， 其 中 抽象 组 件 类 是 所 有 具体 组 件 类 的 公共 
父 类 ， 完 整 类 图 如 图 20-8 所 示 : 
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图 20-8 重 构 后 的 “客户 信息 管理 窗口 ”结构 图 


在 图 20-8 中 ，Component 充 当 抽 和 象 同事 类 ，Button、List、ComboBox 和 TextBox 充 当 具 体 同 事 
类 ，Mediator 充 当 抽 象 中 介 者 类 ，ConcreteMediator 充 当 具 体 中 介 者 类 ，ConcreteMediator 维 持 
了 对 具体 同事 类 的 引用 ， 为 了 简化 ConcreteMediator 类 的 代码 ， 我 们 在 其 中 只 定义 了 一 个 
Button 对 象 和 一 个 TextBox 对 象 。 完 整 代码 如 下 所 示 : 


// 抽 象 中 介 者 
abstract class Mediator { 

public abstract void componentChanged(Component c); 
} 


// 具 体 中 介 者 

class ConcreteMediator extends Mediator { 
// 维 持 对 各 个 同事 对 象 的 引用 
public Button addButton; 
public List list; 
public TextBox userNameTextBox; 
public ComboBox cb; 


// 封 装 同事 对 象 之 间 的 交互 
public void componentCchanged(Component c) { 
// 单 击 按 钮 
if(c == addButton) { 

System.out.println("-- 单 击 增加 按钮 --")， 
list.update( ); 
cb.update( ); 
userNameTextBox.update(); 


} 
// 从 列表 框 选择 客户 
else if(c == list) { 
System.out.println("-- 从 列表 框 选择 客户 --"); 
cb.select(); 
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userNameTextBox.setText(); 


} 

// 从 组 合 框 选择 客户 

else if(c == cb) { 
System.out.,println("-- 从 组 合 框 选择 客户 --")， 
cb.select(); 
userNameTextBox.setText(); 


} 


// 抽 象 组 件 类 : 抽象 同事 类 
abstract class Component { 
protected Mediator mediator; 


public void setMediator(Mediator mediator) { 
this.mediator = mediator; 


} 


// 转 发 调用 
public void changed() { 

mediator .componentChanged( this); 
} 


public abstract void update( ) ; 
} 


// 按 钮 类 : 具体 同事 类 
class Button extends Component { 
public void update() { 
// 按 钮 不 产生 交互 
} 


} 


// 列 表 框 类 : 具体 同事 类 
class List extends Component { 
public void update() { 
System.out.println(" 列 表 框 增加 一 项 : 张 无 态 。"); 
} 


public void select() { 
System.out.println(" 列 表 框 选中 项 : 小 龙 女 。")， 
} 


} 


// 组 合 框 类 : 具体 同事 类 
class ComboBox extends Component { 
public void update() { 
System,out ,println(" 组 合 框 增加 一 项 : 张无忌。")， 
} 


public void select() { 
System.out.println(" 组 合 框 选中 项 : 小 龙 女 。")， 
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} 


// 文 本 框 类 : 具体 同事 类 
class TextBox extends Component { 
public void update() { 
System.out.println(" 客 户 信息 增加 成 功 后 文本 框 清空 。")， 
} 


public void setText() { 
System,out.println(" 文 本 框 显示 : 小 龙 女 。")， 
} 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
// 定 义 中 介 者 对 象 
ConcreteMediator mediator 
mediator = new ConcreteMediator(); 


// 定 义 同事 对 象 

Button addBT = new Button(); 

List list = new List(); 

ComboBox cb = new ComboBox(); 
TextBox userNameTB = new TextBox(); 


addBT.setMediator (mediator ); 
list.setMediator (mediator); 
ch.setMediator (mediator); 
userNameTB.setMediator (mediator); 


mediator.addButton = addBT; 

mediator .1ist = list; 

mediator.cb = cb; 

mediator .userNameTextBox = userNameTB; 


addBT.changed( ); 
System.out.println(----------------------------- 
list.changed( ); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


- - 单 击 增加 按钮 - - 

列表 框 增 加 一 项 : 张 无 总 。 

组 合 框 增加 一 项 : 张无忌 。 
客户 信息 增加 成 功 后 文本 框 清空 。 
- -从 列表 框 选择 客户 -- 

组 合 框 选中 项 : 小 龙 女 。 
文本 框 显示 : 小 龙 女 。 
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协调 乡 个 对 象 之 间 的 交互 一 一 中 介 者 模式 
(四 ) 
协调 乡 个 对 象 之 间 的 交互 一 一 中 介 者 模式 
(四 ) 


人 
Sunny 软 件 公司 CRM 系 统 的 客户 对 “客户 信息 管理 窗口 "提出 了 一 个 修改 意见 : 要 求 在 窗口 的 下 
端 能 够 及 时 显示 当前 系统 中 客户 信息 的 总 数 。 修 改 之 后 的 界面 如 图 20-9 所 示 : 


客户 信息 管理 


请 输入 查询 关键 字 : | 张 盛 扣 








张无忌 姓名 : 张无忌 

杨过 

小 龙 女 性 别 : 四 男 国 女 
令狐冲 

段 内 出 生日 期 : T1980 “| 年 [1 


-证 
联系 电话 : [13000001111 
郭靖 电子 邮箱 : wujl zhang(@®dp.com 


本 系统 中 一 共有 客户 信息 8 条 。 


新 增 组 件 





图 20-9 修改 之 后 的 “客户 信息 管理 窗口 ?界面 图 


从 图 20-9 中 我 们 不 难 发 现 ， 可 以 通过 增加 一 个 文本 标签 (Label) 来 显示 客户 信息 总 数 ， 而 且 当 用 
户 点 击 “ 增 加 ”按钮 或 者 “删除 ”按钮 时 ， 将 改变 文本 标签 的 内 容 。 

由 于 使 用 了 中 介 者 模式 ， 在 原 有 系统 中 增加 新 的 组 件 ( 即 新 的 同事 类 ) 将 变 得 很 容易 ， 我 们 
至 少 有 如 下 两 种 解决 方案 : 

【解决 方案 一 】 增 加 一 个 界面 组 件 类 Label， 修 改 原 有 的 具体 中 介 者 类 ConcreteMediator， 增 加 
一 个 对 Label 对 象 的 引用 ， 然 后 修改 componentChanged() 方 法 中 其 他 相关 组 件 对 象 的 业务 处 理 代 
码 ， 原 有 组 件 类 无 须 任 何 修改 ， 客 户 端 代码 也 需 针 对 新 增 组 件 Label 进 行 适当 修改 。 
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【解决 方案 二 】 与 方案 一 相同 ， 首 先 增加 一 个 Label 类 ， 但 不 修改 原 有 具体 中 介 者 类 
ConcreteMediator 的 代码 ， 而 是 增加 一 个 ConcreteMediator 的 子 类 SubConcreteMediator 来 实现 对 
Label 对 象 的 引用 ， 然 后 在 新 增 的 中 介 者 类 SubConcreteMediator 中 通过 黎 盖 componentChanged0) 
方法 来 实现 所 有 组 件 (包括 新 增 Label 组 件 ) 之 间 的 交互 ， 同 样 ， 原 有 组 件 类 无 须 做 任何 修 
改 ， 客 户 端 代码 需 少 许 修 改 。 


引入 Label 之 后 “客户 信息 管理 窗口 ”类 结构 示意 图 如 图 20-10 所 示 : 


一 















和 
国王 






ComboBox 
图 20-10 增加 Label 组 件 类 后 的 “客户 信息 管理 窗口 ”结构 示意 图 


由 于 【解决 方案 二 】 无 须 修 改 ConcreteMediator 类 ， 更 符合 “ 开 闭 原则 ”， 因 此 我 们 选择 该 解决 
方案 来 对 新 增 Label 类 进行 处 理 ， 对 应 的 完整 类 图 如 图 20-11 所 示 : 
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Component 
{abstract} 
# mediator : Mediator 


+ setMediator (Mediator mediator) : void 

+ change () :void 

+ update () :void 
A A 






Mediator 
{abstract} 


+ componentChanged (Component c) : void 


六 



























| ConcreteMediator | [一 一 
+ addButton : Button 一 
+ list : List + update () :void 
+ UserNameTextBox :TextBox 
+cb :ComboBox 


+ componentChanged (Component c) :void 


人 中 









| 


+ update () :vold 
+ select () :void 






+ Update () :void 
+ setT ext () : void 










+ Update () : void 
+ select() :void 









SubConcreteMediator 
+ label : Label 
+ componentChanged (Component c) :void 


图 20-11 修改 之 后 的 “客户 信息 管理 窗口 ?结构 图 
在 图 20-11 中 ， 新 增 了 具体 同事 类 Label 和 具体 中 介 者 类 SubConcreteMediator， 代 码 如 下 所 示 : 


// 文 本 标签 类 : 具体 同事 类 
class Label extends Component { 
public void update() { 
System.out .printLn(" 文 本 标签 内 容 改 变 ， 客 户 信息 总 数 加 1。") ) 
} 


} 


// 新 增 具 体 中 介 者 类 

class SubConcreteMediator extends ConcreteMediator { 
// 增 加 对 Label 对 象 的 引用 
public Label label; 


public void componentCchanged(Component c) { 
// 单 击 按钮 
if(c == addButton) { 
System.out.println("-- 单 击 增加 按钮 --")，; 
list.update( ); 
cb.update( ); 
userNameTextBox.update(); 
label.update(); // 文 本 标签 更 新 


} 

// 从 列表 框 选择 客户 

else if(c == list) { 
System.out.,println("-- 从 列表 框 选择 客户 --"); 
cb.select(); 
userNameTextBox.setText(); 
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} 

// 从 组 合 框 选择 客户 

else if(c == cb) { 
System.out.,println("-- 从 组 合 框 选择 客户 --")， 
cb.select(); 
userNameTextBox.setText(); 


} 
修改 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
// 用 新 增 具 体 中 介 者 定义 中 介 者 对 象 
SubConcreteMediator mediator 
mediator = new SubConcreteMediator(); 


Button addBT = new Button(); 

List list = new List(); 

ComboBox cb = new ComboBox(); 
TextBox USerNameTB = new TextBox(); 
Label] label = new Label(); 


addBT.setMediator (mediator ); 
list.setMediator (mediator); 
cb.setMediator (mediator); 
userNameTB.setMediator (mediator); 
label.setMediator (mediator ); 


mediator.addButton = addBT; 

mediator .1ist = list; 

mediator.cb = cb; 

mediator .userNameTextBox = userNameTB; 
mediator.label = label; 


addBT.changed( ); 


System,out,println("--------------------------- 


list.changed( ); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


- - 单 击 增加 按钮 - - 

列表 框 增 加 一 项 : 张 无 总 。 

组 合 框 增加 一 项 : 张 无 总 。 

客户 信息 增加 成 功 后 文本 框 清 空 。 

文本 标签 内 容 改 变 ， 客 户 信息 总 数 加 1。 
- -从 列表 框 选择 客户 -- 

组 合 框 选中 项 : 小 龙 女 。 

文本 框 显示 : 小 龙 女 。 
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由 于 在 本 实例 中 不 同 的 组 件 类 ( 即 不 同 的 同事 类 ) 所 拥有 的 方法 并 不 完全 相同 ， 因 此 中 介 者 
类 没有 针对 抽象 同事 类 编程 ， 导 致 在 具体 中 介 者 类 中 需要 维持 对 具体 同事 类 的 引用 ， 容 户 端 
代码 无 法 完全 透明 地 对 待 所 有 同事 类 和 中 介 者 类 。 在 某 些 情况 下 ， 如 果 设 计 得 当 ， 可 以 在 客 
户 端 透明 地 对 同事 类 和 中 介 者 类 编程 ， 这 样 系统 将 具有 更 好 的 灵活 性 和 可 扩展 性 。 


思 考 
如 果 不 使 用 中 介 者 模式 ， 按 照 图 20-3 所 示 设 计 方 案 ， 增 加 新 组 件 时 原 有 系统 该 如 何 修改 ? 


在 中 介 者 模式 的 实际 使 用 过 程 中 ， 如 果 需 要 引入 新 的 具体 同事 类 ， 只 需要 继承 抽象 同事 类 并 
实现 其 中 的 方法 即 可 ， 由 于 具体 同事 类 之 间 并 无 直接 的 引用 关系 ， 因 此 原 有 所 有 同事 类 无 须 
进行 任何 修改 ， 它 们 与 新 增 同事 对 象 之 间 的 交互 可 以 通过 修改 或 者 增加 具体 中 介 者 类 来 实 
现 ; 如 果 需 要 在 原 有 系统 中 增加 新 的 具体 中 介 者 类 ， 只 需要 继承 抽象 中 介 者 类 (或 已 有 的 具 
体 中 介 者 类 ) 并 覆盖 其 中 定义 的 方法 即 可 ， 在 新 的 具体 中 介 者 中 可 以 通过 不 同 的 方式 来 处 理 
对 象 之 间 的 交互 ， 也 可 以 增加 对 新 增 同事 的 引用 和 调用 。 在 客户 端 中 只 需要 修改 少许 代码 
(如 果 引 入 配置 文件 的 话 有 时 可 以 不 修改 任何 代码 ) 就 可 以 实现 中 介 者 的 更 换 。 
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协调 多 个 对 象 之 间 的 交互 一 中介 者 模式 
(五 ) 


协调 多 个 对 象 之 间 的 交互 一 中介 者 模式 
二) 


20.4 中 介 者 模式 总 结 
中 介 者 模式 将 一 个 网 状 的 系统 结构 变 成 一 个 以 中 介 者 对 象 为 中 心 的 星 形 结构 ， 在 这 个 星 型 结 
构 中 ， 使 用 中 介 者 对 象 与 其 他 对 象 的 一 对 多 关系 来 取代 原 有 对 象 之 间 的 多 对 多 关系 。 中 介 者 
模式 在 事件 驱动 类 软件 中 应 用 较为 广泛 ， 特 别 是 基于 GUI (Graphical User Interface， 图 形 用 户 
界面 ) 的 应 用 软件 ， 此 外 ， 在 类 与 类 之 间 存 在 错综复杂 的 关联 关系 的 系统 中 ， 中 介 者 模式 都 
能 得 到 较 好 的 应 用 。 

1. 主要 优点 
中 介 者 模式 的 主要 优点 如 下 : 
(1) 中 介 者 模式 简化 了 对 象 之 问 的 交互 ， 它 用 中 介 者 和 同事 的 一 对 多 交互 代替 了 原来 同事 之 间 
的 多 对 多 交互 ， 一 对 多 关系 更 容易 理解 、 维 护 和 扩展 ， 将 原本 难以 理解 的 网 状 结构 转换 成 相 
对 简单 的 星 型 结构 。 
(2) 中 介 者 模式 可 将 各 同事 对 象 解 烛 。 中 介 者 有 利于 各 同事 之 间 的 松 耦 合 ， 我 们 可 以 独立 的 改 
变 和 复 用 每 一 个 同事 和 中 介 者 ， 增 加 新 的 中 介 者 和 新 的 同事 类 都 比较 方便 ， 更 好 地 符合 “ 开 闭 
原则 ”。 


(3) 可 以 减少 子 类 生成 ， 中 介 者 将 原本 分 布 于 多 个 对 象 间 的 行为 集中 在 一 起 ， 改 变 这 些 行为 只 
需 生成 新 的 中 介 者 子 类 即 可 ， 这 使 各 个 同事 类 可 被 重用 ， 无 须 对 同事 类 进行 扩展 。 


1. 主要 缺点 
中 介 者 模式 的 主要 缺点 如 下 : 


在 具体 中 介 者 类 中 包含 了 大 量 同事 之 间 的 交互 细节 ， 可 能 会 导致 具体 中 介 者 类 非常 复杂 ， 使 
得 系统 难以 维护 。 


1. 适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 中 介 者 模式 : 
(1) 系统 中 对 象 之 间 存 在 复杂 的 引用 关系 ， 系 统 结构 混乱 且 难 以 理解 。 
(2) 一 个 对 象 由 于 引用 了 其 他 很 多 对 象 并 且 直 接 和 这 些 对 象 通信 ， 导 致 难以 复 用 该 对 象 。 
(3) 想 通过 一 个 中 间 类 来 封装 多 个 类 中 的 行为 ， 而 又 不 想 生 成 太 多 的 子 类 。 可 以 通过 引入 中 介 
者 类 来 实现 ， 在 中 介 者 中 定义 对 象 交 互 的 公共 行为 ， 如 果 需 要 改变 行为 则 可 以 增加 新 的 具体 
中 介 者 类 。 
练习 
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Sunny 软 件 公司 欲 开发 一 套图 形 界 面 类 库 。 该 类 库 需 要 包含 若干 预定 义 的 窗 格 (Pane) 对 象 ， 例 
如 TextPane、ListPane、 GraphicPane 等 ， ， 窗 格 之 间 不 允许 直接 引用 。 基 于 该 类 库 的 应 用 由 一 个 
包含 一 组 窗 格 的 窗口 (Window) 组 成 ， 窗 口 需要 协调 窗 格 之 间 的 行为 。 试 采用 中 介 者 模式 设计 
该 系统 。 


2010 年 上 半年 软件 设计 师 下 午 试 卷 第 三 题 
【说 明 ]】 


某 运 输 公司 决定 为 新 的 售 录 机 开发 车 票 销售 的 控制 软件 。 图 I 给 出 了 售票 机 的 面板 示意 图 以 及 
相关 的 控制 部 件 。 


一 些 操作 说 明 





滨 续 / 取 衣 鲍 


| 


目的 地 键盘 车 票 键盘 纹 币 档 
图 I 售票 机 面板 示意 图 
售票 机 相关 部 件 的 作用 如 下 所 述 : 
(1) 目的 地 键盘 用 来 输入 行程 目的 地 的 代码 (例如 ，200 表 示 总 站 ) 。 
(2) 乘客 可 以 通过 车 票 键盘 选择 车 票 种 类 〈 单 程 票 、 多 次 往返 票 和 座席 种 类 ) 。 
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(3) 继续 /取消 键盘 上 的 取消 按钮 用 于 取消 购 票 过 程 ， 继 续 按 钮 允许 乘客 连续 购买 多 张 票 。 
(4) 显示 屏 显 示 所 有 的 系统 输出 和 用 户 提示 信息 

(5) 插 卡 口 接受 MCard (现金 卡 ) ， 硬 币 口 和 纸币 槽 接受 现金 。 

(6) 打印 机 用 于 输出 车 票 。 

(7) 所 有 部 件 均 可 实现 自 检 并 恢复 到 初始 状态 。 


现 采 用 面向 对 象 方法 开发 该 系统 ， 使 用 UML 进 行 建 模 ， 系 统 的 顶层 用 例 图 和 类 图 分 别 如 图 IT 和 
图 III 所 示 。 


0° 


图 I 顶层 用 例 图 





选择 目的 地 和 
车 更 类 型 





3 (1) 时 
1 (CY 





S 维护 售票 机 
A2 ] 





图 II 类 图 
【问题 1] 


根据 说 明 中 的 描述 ， 给 出 图 II 中 A1 和 A2 所 对 应 的 执行 者 ，U1 所 对 应 的 用 例 ， 以 及 (1)、(2) 处 所 
对 应 的 关系 。 


【 问题 2 】 

根据 说 明 中 的 描述 ， 给 出 图 II[ 中 缺少 的 C1-C4 所 对 应 的 类 名 以 及 (3)-(6) 处 所 对 应 的 多 重度 。 
【问题 3】 

图 III 中 的 类 图 设计 采用 了 中 介 者 (Mediator) 设 计 模 式 ， 请 说 明 该 模式 的 内 涵 。 
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各 忘 录 模 式 -Memento Pattern 


各 忘 录 模 式 -Memento Pattern 


备忘录 模式 -Memento Pattern 【学 习 难 度 : 砍 克 六 交 六 ， 使 用 频率 : 交友 六 六 六 】 


e。 备忘录 模式 -Memento Pattern 
o 撤销 功能 的 实现 备忘录 模式 (一 








o 撤销 功能 的 实现 一 备忘录 模式 
撤销 功能 的 实现 一 备忘录 模式 











2 
。 撤销 功能 的 实现 一 备忘录 模式 (四 
o 二 


撤销 功能 的 实现 一 备忘录 模式 
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每 个 人 都 有 过 后 悔 的 时 候 ， 但 人 生 并 无 后 悔 药 ， 有 些 错误 一 旦 发 生 就 无 法 再 挽回 ， 有 些 人 一 
旦 错过 就 不 会 再 回来 ， 有些 话 一 旦 说 出 口 就 不 可 能 再 收回 ， 这 就 是 人 人生。 为 了 不 后 悔 ， 凡 事 
我 们 都 需要 三 思 而 后 行 。 说 了 这 么 多 ， 大 家 可 能 已 经 尝 了 ， 不 是 在 学 设计 模式 吗 ? 为 什么 再 
出 这 么 一 堆 人 生 感 悟 来 ， 呵 呵 ， 别 着 急 ， 本 章 将 介绍 一 种 让 我 们 可 以 在 软件 中 实现 后 悔 机 制 
的 设计 模式 备忘录 模式 ， 它 是 软件 中 的 “后 悔 药 p， 是 软件 中 的 “月 光 宝 盒 ”。 话 不 多 说 ， 下 
面 就 让 我 们 进入 备忘录 模式 的 学 习 。 

21.1 可 悔 棋 的 中 国 象棋 

Sunny 软 件 公司 欲 开 发 一 款 可 以 运行 在 Android 平 台 的 触摸 式 中 国 象 棋 软 件 ， 由 于 考虑 到 有 些 用 
户 是 “菜鸟 ”， 经 常 不 小 心 走 错 棋 ; 还 有 些 用 户 因 为 不 习惯 使 用 手指 在 手机 屏幕 上 拖 动 棋子 ， 常 


常 出 现 操 作 失 误 ， 因 此 该 中 国 象 棋 软 件 要 提供 “ 悔 棋 ”功能 ， 用 户 走 错 棋 或 操作 失误 后 可 恢复 到 
前 一 个 步骤 。 如 图 21-1 所 示 : 


1 
pall 








2 














\ Ar 一/ ma 上 


图 21-1 Android 版 中 国 象棋 软件 界面 示意 图 
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如 何 实现 “ 悔 棋 ” 功 能 是 Sunny 软 件 公 司 开 发 人 员 需 要 面 对 的 一 个 重要 问题 ，“ 悔 棋 ” 就 是 让 系统 
恢复 到 某 个 历史 状态 ， 在 很 多 软件 中 通常 称 之 为 “撤销 ”。 下面 我 们 来 简单 分 析 一 下 撤销 功能 的 
实现 原理 : 

在 实现 撤销 时 ， 首 先 必须 保存 软件 系统 的 历史 状态 ， 当 用 户 需要 取消 错误 操作 并 且 返 回 至 
个 历史 状态 时 ， 可 以 取出 事先 保存 的 历史 状态 来 覆盖 当前 状态 。 如 图 21-2 所 示 : 


1 茶 





图 21-2 撤 销 功 能 示意 图 
备忘录 模式 正 为 解决 此 类 撤销 问题 而 诞生 ， 它 为 我 们 的 软件 提供 了 “后 悔 药 *”， 通 过 使 用 备 
模式 可 以 使 系统 恢复 到 某 一 特定 的 历史 状态 。 
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撤销 功能 的 实现 一 一 备忘录 模式 (二 ) 
撤销 功能 的 实现 一 一 备忘录 模式 (二 ) 


21.2 备忘录 模式 概述 

备忘录 模式 提供 了 一 种 状态 恢复 的 实现 机 制 ， 使 得 用 户 可 以 方便 地 回 到 一 个 特定 的 历史 步 

又 ， 当 新 的 状态 无 效 或 者 存在 问题 时 ， 可 以 使 用 暂时 存储 起 来 的 备忘录 将 状态 复原 ， 当 前 很 

多 软件 都 提供 了 撤销 (Undo) 操 作 ， 其 中 就 使 用 了 备忘录 模式 。 

备忘录 模式 定义 如 下 : 
备忘录 模式 (Memento Pattern) : 在 不 破坏 封装 的 前 提 下 ， 捕 获 一 个 对 象 的 内 部 状态 ， 并 在 
该 对 象 之 外 保存 这 个 状态 ， 这 样 可 以 在 以 后 将 对 象 恢复 到 原先 保存 的 状态 。 它 是 一 种 对 
象 行为 型 模式 ， 其 别名 为 Token。 

备忘录 模式 的 核心 是 备忘录 类 以 及 用 于 管理 备忘录 的 负责 人 类 的 设计 ， 其 结构 如 图 21-3 所 示 : 


Originator Memento 


+ restoreMemento (Memento m + getState () 
+ createMemento () + setState () 
~ 一 memento 
retum new Memento (state); state=m.getState(); 













21-3 备忘录 模式 结构 图 
在 备忘录 模式 结构 图 中 包含 如 下 几 个 角色 : 


e Originator ( 原 发 器 ) : 它 是 一 个 普通 类 ， 可 以 创建 一 个 备忘录 ， 并 存储 它 的 当前 内 部 状 
态 ， 也 可 以 使 用 备忘录 来 恢复 其 内 部 状态 ， 一 般 将 需要 保存 内 部 状态 的 类 设计 为 原 发 器 。 


eMemento (备忘录 ) : 存储 原 发 器 的 内 部 状态 ， 根 据 原 发 器 来 决定 保存 哪些 内 部 状态 。 备 忘 录 
的 设计 一 般 可 以 参考 原 发 器 的 设计 ， 根 据 实际 需要 确定 备忘录 类 中 的 属性 。 需 要 注意 的 是 ， 

除了 原 发 器 本 身 与 负责 人 类 之 外 ， 备 忘 录 对 象 不 能 直接 供 其 他 类 使 用 ， 原 发 器 的 设计 在 不 同 

的 编程 语言 中 实现 机 制 会 有 所 不 同 。 


eCaretaker (负责 人 ) : 负责 人 又 称 为 管理 者 ， 它 负责 保存 备忘录 ， 但 是 不 能 对 备忘录 的 内 容 
进行 操作 或 检查 。 在 负责 人 类 中 可 以 存储 一 个 或 多 个 备忘录 对 象 ， 它 只 负责 存储 对 象 ， 而 不 
能 修改 对 象 ， 也 无 须知 道 对 象 的 实现 细节 。 


理解 备忘录 模式 并 不 难 ， 但 关键 在 于 如 何 设计 备忘录 类 和 负责 人 类 。 由 于 在 备忘录 中 存储 的 
是 原 发 器 的 中 间 状 态 ， 因 此 需要 防止 原 发 器 以 外 的 其 他 对 象 访问 备忘录 ， 特 别 是 不 允许 其 他 
对 象 来 修改 备忘录 。 

下 面 我 们 通过 简单 的 示例 代码 来 说 明 如 何 使 用 Java 语 言 实现 备忘录 模式 : 
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撤销 功能 的 实现 一 一 备忘录 模式 (二) 


在 使 用 备忘录 模式 时 ， 首 先 应 该 存在 一 个 原 发 器 类 Originator， 在 丨 实业 务 中 ， 原 发 器 类 是 一 
个 具体 的 业务 类 ， 它 包含 一 些 用 于 存储 成 员 数 据 的 属性 ， 典 型 代码 如 下 所 示 : 


package dp.memento; 
public class Originator { 
private String state; 


public Originator(){} 


// 创建 一 个 备忘录 对 象 
public Memento createMemento() { 
return new Memento(this ) ， 


} 


// 根据 备忘录 对 象 恢复 原 发 器 状态 
public void restoreMemento(Memento m) { 
state = m.state; 


} 


public void setState(String state) { 
this.state=state; 


} 


public String getState() { 
return this.state; 
} 
} 


对 于 备忘录 类 Memento 而 言 ， 它 通常 提供 了 与 原 发 器 相对 应 的 属性 (可 以 是 全 部 ， 也 可 以 是 部 
分 ) 用 于 存储 原 发 器 的 状态 ， 典 型 的 备忘录 类 设计 代码 如 下 : 


package dp.memento; 
// 备 忘 录 类 ， 默 认可 见 性 ， 包 内 可 见 
class Memento { 

private String state; 


public Memento(Originator o) { 
state = o.getSstate(); 


} 


public void setState(String state) { 
this.state=state; 


} 


public String getState() { 
return this.state; 
} 
} 


在 设计 备忘录 类 时 需要 考虑 其 封装 性 ， 除 了 Originator 类 ， 不 允许 其 他 类 来 调用 备忘录 类 
Memento 的 构造 函数 与 相关 方法 ， 如 果 不 考 虑 封装 性 ， 人 允许 其 他 类 调用 setState() 等 方法 ， 将 寻 
致 在 备忘录 中 保存 的 历史 状态 发 生 改 变 ， 通 过 撤销 操作 所 恢复 的 状态 就 不 再 是 真实 的 历史 状 
态 ， 备 忘 录 模 式 也 就 失去 了 本 身 的 意义 。 
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在 使 用 Java 语 言 实现 备忘录 模式 时 ， 一 般 通 过 将 Memento 类 与 7 Originator 类 定义 在 同一 个 包 
(package) 中 来 实现 封装 ， 在 Java 语 言 中 可 使 用 默认 访问 标识 符 来 定义 Memento 类 ， 即 保证 其 包 
内 可 见 。 只 有 Originator 类 可 以 对 Memento 进 行 访 问 ， 而 限制 了 其 他 类 | 0 的 访问 。 "在 
Memento 中 保存 了 Originator 的 state 值 ， 如 果 Originator 中 的 state 值 改变 需 撤销 ， 可 以 通过 调 
用 它 的 restoreMemento() 方 法 进行 恢复 。 

对 于 负责 人 类 Caretaker ， 于 保存 备忘录 对 象 ， 并 提供 getMemento() 方 法 用 于 向 客户 端 

一 个 备忘录 对 象 ， 原 发 器 通过 使 用 这 个 备忘录 对 象 可 以 回 到 某 个 历史 状态 。 典 型 的 负责 全 
的 实现 代码 如 下 : 


package dp,memento 
public class Caretaker { 
private Memento memento; 


public Memento getMemento() { 
return memento; 
} 


public void setMemento(Memento memento) { 
this .memento=memento ; 
} 


} 

在 Caretaker 类 中 不 应 该 直接 调用 Memento 中 的 状态 改变 方法 ， 它 的 作用 仅仅 用 于 存储 备忘录 对 
象 。 将 原 发 器 备份 生成 的 备忘录 对 象 存储 在 其 中 ， 当 用 户 需 要 对 原 发 器 进行 恢复 时 再 将 存储 
在 其 中 的 备忘录 对 象 取出 。 

思考 


否 通过 原型 模式 来 创建 备忘录 对 象 ? 系统 该 如 何 设计 ? 
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21.3 完整 解决 方案 


为 了 实现 撤销 功能 ，Sunny 公 司 开发 人 员 决 定 使 用 备忘录 模式 来 设计 中 国 象棋 软件 ， 其 基本 结 
构 如 图 21-4 所 示 : 





21-4 中 国 象棋 棋子 撤销 功能 结构 图 。 


在 图 21-4 中 ，Chessman 充 当 原 发 器 ，ChessmanMemento 充 当 备 忘 录 ，MementoCaretaker 充 当 负 
责 人 ， 在 MementoCaretaker 中 定义 了 一 个 ChessmanMemento 类 型 的 对 象 ， 用 于 存储 备忘录 。 完 
整 代码 如 下 所 示 : 


// 象 棋 棋 子 类 : 原 发 器 

class Chessman { 
private String label; 
private int x; 
private int y; 


public Chessman(String label,int x,int y) { 
this.1label = label; 
this.x = x; 
this.y = y; 

} 


public void setLabel(String label) { 
this.1label = label; 
} 


public void setXx(int x) { 
this.x = x; 
} 
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撤销 功能 的 实现 一 一 备忘录 模式 (三) 


public void setY(int y) { 
this.y = y; 
} 


public String getLabel() { 
return (this.1label); 
} 


public int getX() { 
return (this.x); 
} 


public int getY() { 
return (this.y); 
} 


// 保 存 状 态 
public ChessmanMemento save() { 

return new ChessmanMemento(this.1label, this.x, this.y); 
} 


// 恢 复 状 态 

public void restore(ChessmanMemento memento) { 
this.1label = memento.getLabel(); 
this.x memento .getX()， 
this.y = memento.getY(); 


} 


// 象 棋 棋 子 备忘录 类 : 备忘录 

class ChessmanMemento { 
private String label; 
private int x; 
private int y; 


public ChessmanMemento(String label,int x,int y) { 
this.1label = label; 
this.x = x; 
this.y = y; 

} 


public void setLabel(String label) { 
this.1label = label; 
} 


public void setx(int x) { 
this.x = x; 


} 

public void setY(int y) { 
this.y = y; 

} 
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public String getLabel() { 
return (this.1label); 
} 


public int getX() { 
return (this.x); 
} 


public int getY() { 
return (this.y); 
} 


} 


// 象 棋 棋 子 备忘录 管理 类 : 负责 人 
class MementoCaretaker { 
private ChessmanMemento memento; 


public ChessmanMemento getMemento() { 
return memento; 
} 


public void setMemento(ChessmanMemento memento) { 
this.memento = memento ， 
} 


编写 如 下 客户 端 测试 代码 : 
[java] view plain copy 
class Client { 
public static void main(String args[]) { 

MementoCaretaker mc = new MementoCaretaker(); 
Chessman chess = new Chessman(" 车 ",1,1); 
display(chess); 
mc.setMemento(chess.save()); // 保 存 状 态 
chess.setY(4); 
display(chess); 
mc.setMemento(chess.save()); // 保 存 状 态 
display(chess);，; 
chess.setX(5); 
display(chess); 
System.out.println("****** 悔 棋 ******")， 
chess.restore(mc.getMemento()); // 恢 复 状态 
display(chess); 


} 


} 


public static void display(Chessman chess) { 
System.out.println(" 棋 子 " + chess.getLabel() + "当前 位 置 为 :" + 
} 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


棋子 车 当前 位 置 为 : 第 1 行 第 1 列 。 
棋子 车 当前 位 置 为 : 第 1 行 第 4 列 。 
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撤销 功能 的 实现 一 一 备忘录 模式 (三) 


棋子 车 当前 位 置 为 : 第 1 行 第 4 有 
棋子 车 当前 位 置 为 : 第 5 行 第 4 列 。 


** 炎 火炎 火炎 悔 本 大 类 类 类 类 类 
六 


棋子 车 当前 位 置 为 : 第 1 行 第 4 列 。 
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21.4 实现 多 次 撤销 


Sunny 软 件 公司 开发 人 员 通 过 使 用 备忘录 模式 实现 了 中 国 象 棋 棋 子 的 撤销 操作 ， 但 是 使 用 上 述 
代码 只 能 实现 一 次 撤销 ， 因 为 在 负责 人 类 中 只 定义 一 个 备 蕊 9 后 面 保存 的 


ee 复 盖 ， 但 有 时 候 用 户 需要 撤销 多 步 操作 。 a 
本 节 将 提供 1 次 撤销 的 解决 方案 ， 那 就 是 在 负责 人 类 中 se 多 个 
录 ， 每 个 录 负 责 保存 一 个 历史 状态 ， 在 撤销 时 可 以 对 备 忘 采集 全 进行 北向 亿 历 ， 回 到 一 


个 指 0 而 且 还 可 以 对 备忘录 集合 进行 正 向 遍历 ， 实 现 重 做 (Redo) 操 作 ， 即 取消 撤 
销 ， 让 对 象 状态 得 到 恢复 。 


改进 之 后 的 中 国 象棋 棋子 撤销 功能 结构 图 如 图 21-5 所 示 : 




















Chessman 
- label : String ChessmanMemento 
- X -int - label : String 
-Y :int -Xx :int 
+ Chessman (String label, int x, int y) -yY :int 
+ getLabel () : String + ChessmanMemento (String label, int x, 
+ setLabel (String label) : void 一 一 一 于 | inty) 
+ getX () : int + getLabel () : String 
+ SetX (int x) : void + setLabel (String label) :void 
+ getY () : int + getX () :int 
+ setY (int y) : void + SetX (int x) -void 
+ save () : ChessmanMemento + gety () :int 
+ restore (ChessmanMemento memento) : void + SetY (inty) :void 














二 
MementoCaretaker 


- mementolist : ArrayList 
+ getMemento (int i) :ChessmanMemento 
+ setMemento (ChessmanMemento memento) : void 


图 21-s 改进 之 后 的 中 国 象 棋 棋 子 撤销 功能 结构 图 。 





在 图 21-5 中 ， 我 们 对 负责 了 修改 ， 在 其 中 定义 了 一 个 ArrayList 类 型 
的 集合 对 象 来 存储 多 个 其 代码 如 下 所 示 : 


import java.util.*,; 

class MementoCaretaker { 
// 定 义 一 个 集合 来 存储 多 个 备忘录 
private ArrayList mementolist = new ArrayList(); 
public ChessmanMemento getMemento(int i) { 


return (ChessmanMemento)mementolist.get(i); 
} 


public void setMemento(ChessmanMemento memento) { 
mementolist.add(memento); 
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编写 如 下 客户 端 测试 代码 : 


class Client { 


private 


static int index = -1; // 定 义 一 个 索引 来 记录 当前 状态 所 在 位 置 


private static MementoCaretaker mc = new MementoCaretaker(); 


public static void main(String args[]) { 


} 


Chessman chess = new Chessman(" 车 ",1,1); 
play(chess); 

chess.setY(4); 

play(chess); 

chess.setX(5); 

play(chess); 

undo(chess, index ); 

undo(chess, index ); 

redo(chess, index ) ; 

redo(chess, index ) ; 


// 下 棋 
public static void play(Chessman chess) { 


Index ++; 

System.out.println(" 棋 子 " + chess.getLabel() + "当前 位 置 为 : 
} 
// 悔 棋 


mc.setMemento(chess.save()); // 保 存 备 忘 录 


public static void undo(Chessman chess,int i) { 


} 


System.out .printLn("**xxxx 悔 棋 *xxxxxn)) 
Index --; 
chess.restore(mc.getMemento(i-1)); // 撤 销 到 上 一 个 备忘录 


System.out.println(" 棋 子 " + chess.getLabel() + "当前 位 置 为 : 


// 撤 销 悔 棋 
public static void redo(Chessman chess,int i) { 


} 


System.out.println("****** 撤 销 悔 权 ******")， 
index ++; 
chess.restore(mc.getMemento(i+1)); // 恢 复 到 下 一 个 备忘录 


System.out.println(" 棋 子 " + chess.getLabel() + "当前 位 置 为 : 


编译 并 运行 程序 ， 输 出 结果 如 下 : 


棋子 车 当前 位 置 为 : 第 1 行 第 1 列 。 
棋子 车 当前 位 置 为 : 第 1 行 第 4 列 。 
棋子 车 当前 位 置 为 : 第 5 行 第 4 列 。 


x xx 大 yx 悔 


棋 关 大 关 炎 炎 关 
六 


棋子 车 当前 位 置 为 : 第 1 行 第 4 列 。 


x xx 大 xx 悔 





棋 关 大 交火 类 类 
六 


棋子 车 当前 位 置 为 : 第 1 行 第 1 列 。 


xxxx 大 x 撤 
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销 悔 相 类 类 类 类 类 类 


撤销 功能 的 实现 一 一 备忘录 模式 (四 ) 


棋子 车 当前 位 置 为 : 第 1 行 第 4 列 。 
*** 太 w*** 撤 销 悔 棋 ****** 
棋子 车 当前 位 置 为 : 第 5 行 第 4 列 。 


扩展 
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本 实例 只 能 实现 最 简单 的 Undo 和 Redo 操 作 ， 并 未 考虑 对 象 状态 在 操作 过 程 中 出 现 分 支 的 
情况 。 如 果 在 撤销 到 某 个 历史 状态 之 后 ， 用 户 再 修改 对 象 状 态 ， 此 后 执行 Undo 操 作 时 可 
能 会 发 生 对 象 状态 错误 ， 大 家 可 以 思考 其 产生 原因 。【 注 : 可 将 对 象 状态 的 改变 绘制 成 
一 张 树 状 图 进行 分 析 。】 


在 实际 开发 中 ， 可 以 使 用 链表 或 者 堆栈 来 处 理 有 分 支 的 对 象 状态 改变 ， 大 家 可 通过 链表 
或 者 堆栈 对 上 述 实例 进行 改进 。 
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21.5 再 谈 备 忘 录 的 封装 


备忘录 是 一 个 很 特殊 的 对 象 ， 只 有 原 发 器 对 它 拥有 控 币 人 责 人 只 负责 管理 ， 而 其 他 
类 无 法 访问 到 备忘录 ， 因 此 我 们 需要 对 备忘录 进行 封装 


为 了 实现 对 备忘录 对 象 的 封装 ， 需 要 对 备忘录 的 调用 进行 控制 ， 对 于 原 发 器 而 言 ， 0 
用 备忘录 的 所 有 信息 ， A de a 对 于 负责 人 而 言 

只 负责 备忘录 的 保存 并 将 备忘录 传递 给 其 他 对 象 ; 对 于 其 他 对 象 而 言 ， 只 需要 从 负责 人 处 到 
出 备忘录 对 象 并 将 原 发 器 对 象 的 状态 恢复 ， 而 无 须 关心 备忘录 的 保存 细 芝 。 理 想 的 情 况 是 只 
允许 生成 该 备忘录 的 那个 原 发 器 访问 备忘录 的 内 部 状态 。 


在 实际 开发 中 ， 原 发 器 与 备忘录 之 间 的 关系 是 非常 特殊 的 ， 它 们 要 分 享 信息 而 不 让 其 他 类 知 
道 ， 实 现 的 方法 因 编 程 语 言 的 不 同 而 有 所 差异 ， 在 C++ 中 可 以 使 用 friend 关 键 字 ， 让 原 发 器 类 
和 备忘录 类 成 为 友 元 类 ， 互 相 之 间 可 以 访问 对 象 的 一 些 私 有 的 属性 ; 在 Java 语 言 中 可 以 将 原 发 
器 类 和 备忘录 类 放 在 一 个 包 中 ， 让 它们 之 间 满 足 默认 的 包 内 可 见 性 ， 也 可 以 将 备忘录 类 作为 
原 发 器 类 的 内 部 类 ， 使 得 只 有 原 发 器 才 可 以 访问 备忘录 中 的 数据 ， 其 他 对 象 都 无 法 使 用 备 忘 
录 中 的 数据 。 
思考 
如 何 使 用 内 部 类 来 实现 备忘录 模式 ? 
21.6 备忘录 模式 总 结 
备忘录 模式 在 很 多 软件 的 使 用 过 程 中 普遍 存在 ， 但 是 在 应 用 软件 开发 中 ， 它 的 使 用 频率 并 不 
太 高 ， 因 为 现在 很 多 基于 窗 体 和 浏览 器 的 应 用 软件 并 没有 提供 撤销 操作 。 如 果 需 要 为 软件 提 
供 撤销 功能 ， 备 忘 录 模 式 无 疑 是 一 种 很 好 的 解决 方案 。 在 一 些 字 处 理 软件 、 图 像 编辑 软件 、 
数据 库 管 理 系统 等 软件 中 备忘录 模式 都 得 到 了 很 好 的 应 用 。 
1. 主 要 优点 
备忘录 模式 的 主要 优点 如 下 : 


(GD) 它 提供 了 一 种 状态 恢复 的 实现 机 制 ， 使 得 用 户 可 以 方便 地 回 到 一 个 特定 的 历史 步骤 ， 当 新 
的 状态 无 效 或 者 存在 问题 时 ， 可 以 使 用 暂时 存储 起 来 的 备忘录 将 状态 复原 。 


(2) 备 忘 录 实 现 了 对 信息 的 封装 ， 一 个 备忘录 对 象 是 一 种 原 发 器 对 象 状态 的 表示 ， 不 会 被 其 他 

备忘录 保存 了 原 发 器 的 状态 ， 采 用 列表 、 堆 栈 等 集合 来 存储 备忘录 对 象 可 以 实 
见 多 次 撤销 操作 。 

2. 主 要 缺点 

备 意 录 模 式 的 主要 缺点 如 下 : 


资源 消耗 过 大 ， 如 果 需 要 保存 的 原 发 器 类 的 成 员 变 量 太 多 ， 就 不 可 避免 需要 占用 大 量 的 存储 
定 间 ， 每 保育 一 次 对 象 的 状态 都 需要 消耗 一 定 的 系统 资源 。 


3. 适 用 场景 
361 


撤销 功能 的 实现 一 一 备忘录 模式 (五) 


在 以 下 情况 下 可 以 考虑 使 用 备忘录 模式 : 

(D 保 存 一 个 对 象 在 某 一 个 时 刻 的 全 部 状态 或 部 分 状态 ， 这 样 以 后 需要 时 它 能 够 恢复 到 先前 的 

状态 ， 实 现 撤销 操作 。 

(2) 防 止 外 界 对 象 破坏 一 个 对 象 历史 状态 的 封装 性 ， 避 免 将 对 象 历史 状态 的 实现 细节 暴露 给 外 

界 对 象 。 

练习 
Sunny 软 件 公司 正在 开发 一 款 RPG 网 游 ， 为 了 给 玩家 提供 更 多 方便 ， 在 游戏 过 程 中 可 以 设 
置 一 个 恢复 点 ， 用 于 保存 当前 的 游戏 场景 ， 如 果 在 后 续 游戏 过 程 中 玩家 角色 “不 幸 牺 牲 ”， 
可 以 返回 到 先前 保存 的 场景 ， 从 所 设 恢 复 点 开始 重新 游戏 。 试 使 用 备忘录 模式 设计 该 功 


化 
月 已 2 
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观 罕 者 模式 -Observer Pattern 


观察 者 模式 -Observer Pattern 【学 习 难 度 : 龙 友 让 闪闪 ， 使 用 频率 : 交友 六 交 克 】 


e 观察 者 模式 -Observer Pattern 
对 象 间 的 联动 
对 象 间 的 联动 一 观察 者 模式 
对 象 间 的 联动 -观察 者 模式 





观察 者 模式 (一 











对 象 间 的 联动 观察 者 模式 
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四 
对 象 间 的 联动 观察 者 模式 (五 
对 象 间 的 联动 六 


观察 者 模式 (六 
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对 象 间 的 联动 一 观察 者 模式 (一 ) 
对 象 间 的 联动 一 观察 者 模式 (一 ) 


观察 者 楼 式 是 设计 楼 式 中 的 “超级 楼 式 *， 其 应 用 随处 可 见 ， 在 之 后 几 篇 文章 里 ， 我 将 向 大 家 详 
细 介 绍 观察 者 模式 。 


“ 红 灯 停 ， 绿 灯 行 ”， 在 日 常生 活 中 ， 交 通信 号 灯 装 点 着 我 们 的 城市 ， 指 挥 着 日 益 拥挤 的 城市 交 
通 。 当 红 灯 亮 起 ， 来 往 的 汽车 将 停止 ; 而 绿灯 亮 起 ， 汽 车 可 以 继续 前 行 。 在 这 个 过 程 中 ， 交 
通信 号 灯 是 汽车 〈( 更 准确 地 说 应 该 是 汽车 驾驶 员 ) 的 观察 目标 ， 而 汽车 是 观察 者 。 随 着 交通 
信号 灯 的 变化 ， 汽 车 的 行为 也 将 随 之 而 变化 ， 一 理 交 通信 号 灯 可 以 指挥 多 辆 汽车 。 如 图 22-1 所 





图 22-1 交通 信号 灯 与 汽车 示意 图 


【插曲 : 本 图 是 根据 网 络 上 一 张 图 PS 的 ， 但 改 为 黑白 图 片 之 后 我 把 那 张 彩 色 的 原始 图 片 删除 
了 ， 后 悔 mg.…， 怎 么 根据 黑白 图 片 查询 彩色 图 片 啊 ， 这 样 的 工具 ， 有 木 有 ! ! 那 张 彩色 的 原 
图 很 漂亮 ， 有 木 有 人 能 够 帮 我 找 一 找 ， 大 器】 


在 软件 系统 中 ， 有 些 对 象 之 间 也 存在 类 似 交通 信号 灯 和 汽车 之 间 的 关系 ， 一 个 对 象 的 状态 或 
行为 的 变化 将 导致 其 他 对 象 的 状态 或 行为 也 发 生 改 变 ， 它 们 之 间 将 产生 联动 ， 正 所 谓 “ 触 一 而 
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牵 百 发 ”。 为 了 更 好 地 描述 对 象 之 问 存 在 的 这 种 一 对 多 (包括 一 对 一 ) 的 联动 ， 观 察 者 模式 应 
运 而 生 ， 它 定义 了 对 象 之 间 一 种 一 对 多 的 依赖 关系 ， 让 一 个 对 象 的 改变 能 够 影响 其 他 对 象 。 
本 章 我 们 将 学 习 用 于 实现 对 象 间 联 动 的 观察 者 模式 。 


22.1 多 人 联机 对 战 游 戏 的 设计 

Sunny 软 件 公司 欲 开 发 一 款 多 人 联机 对 战 游戏 (类似 魔兽 世界 、 星 际 争霸 等 游戏 ) ， 在 该 游戏 
中 ， 多 个 玩家 可 以 加 入 同一 战队 组 成 联盟 ， 当 战队 中 某 一 成 员 受 到 数 人 攻击 时 将 给 所 有 其 他 
盟友 发 送 通知 ， 盟 友 收 到 通知 后 将 作出 响应 。 

Sunny 软 件 公司 开发 人 员 需 要 提供 一 个 设计 方案 来 实现 战队 成 员 之 间 的 联动 。 


> 过 对 系统 功能 需求 进行 分 析 ， 发 现在 该 系统 中 战队 成 员 之 间 的 联动 
过 程 可 以 简单 描述 如 下 : 


联盟 成 员 受 到 攻击 --> 发 送 通知 给 盟友 --> 盟 友 作 出 响应 。 


如 果 按 照 上 述 思 路 来 设计 系统 ， 由 于 联盟 成 员 在 受到 攻击 时 需要 通知 他 的 每 一 个 盟友 ， 因 此 

每 个 联盟 成 员 都 需要 持 有 其 他 所 有 盟友 的 信息 ， 这 将 导致 系统 开销 较 大 ， 因 此 Sunny 公 司 开 发 

人 员 决 定 引 入 一 个 新 的 角色 一 “战队 控制 中 心 ” 来 负责 维护 和 管理 每 个 战队 所 有 成 员 的 信 

息 。 术 受到 攻击 时 ， 将 向 相应 的 战队 控制 中 心 发 送 求助 信息 息 ， 战 队 控制 中 心 再 
通知 每 个 盟友 ， 盟 友 再 作出 响应 ， 如 图 22-2 所 示 : 


ee, 战队 控 
制 中 心 


发 布 求助 信息 
- |e 1 
通知 成 员 


受到 攻击 支援 盟友 





图 22-2 多 人 联机 对 战 游 戏 中 对 象 的 联动 


在 图 22-2 中 ， 受 攻击 的 联盟 成 员 将 与 战队 控制 中 心 产 生 联 动 ， 战 队 控制 中 心 还 将 与 其 他 盟友 产 
生 联动 。 


如 何 实现 对 象 之 间 的 联动 ? 如 何 让 一 个 对 象 的 状态 或 行为 改变 时 ， 依赖 于 它 的 对 象 能 够 得 到 
通知 并 进行 相应 的 处 理 ? 


别 着 急 ， 本 章 所 介绍 的 观察 者 模式 将 为 对 象 之 间 的 联动 提供 一 个 优秀 的 解决 方案 ， 下 面 就 让 
我 们 正式 进入 观察 者 模式 的 学 习 。 


365 


对 象 间 的 联动 观察 者 模式 (二) 





对 象 间 的 联动 
对 象 间 的 联动 


22.2 观察 者 模式 概述 





观察 者 模式 (二 ) 
观察 者 模式 (二 ) 





观察 者 模式 是 使 用 频率 最 高 的 设计 模式 之 一 ， 它 用 于 建立 一 种 对 象 与 对 象 之 间 的 依赖 关系 ， 
一 个 对 象 发 生 改 变 时 将 自动 通知 其 他 对 象 ， 其 他 对 象 将 相应 作出 反应 。 在 观察 者 模式 中 ， 发 
生 改 变 的 对 象 称 为 观察 目标 ， 而 被 通知 的 对 象 称 为 观察 者 ， 一 个 观察 目标 可 以 对 应 多 个 观察 
者 ， 而 且 这 些 观 察 者 之 间 可 以 没有 任何 相互 联系 ， 可 以 根据 需要 增加 和 删除 观察 者 ， 使 得 系 
统 更 易于 扩展 。 


观察 者 模式 定义 如 下 : 观察 者 模式 (Observer Pattern) : 定义 对 象 之 间 的 一 种 一 对 多 依赖 关系 ， 

使 得 每 当 一 个 对 象 状 态 发 生 改 变 时 ， 其 相关 依赖 对 象 丝 得 到 通知 并 被 自动 更 新 。 观 察 者 模式 
的 别名 包括 发 布 -订阅 (Publish/Subscribe ) 模式 、 模 型 -视图 (Model/View) 模式 、 源 -监听 器 
(Source/Listener) 模式 或 从 属 者 (Dependents) 模式 。 观 察 者 模式 是 一 种 对 象 行为 型 模式 。 


观察 者 模式 结构 中 通常 包括 观察 目标 和 观察 者 两 个 继承 层次 结构 ， 其 结构 如 图 22-3 所 示 : 








Opsever ~ 


+ Update () 
人 


observers 








+ attach (Observer obs) 
+ detach (Observer obs) 


+ notify () 












be for(obs:observers){ 
obs.update(); 


} 









ConcreteSubject 
- SubjectState : 


+ getState ()、 
+ setState () 人、、 
了 
return subjectState. 2 


’ 


observerState=subject.getState(); 


ConcreteObserver 
- ObserverState : 
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图 22-3 观察 者 模式 结构 图 
在 观察 者 模式 结构 图 中 包含 如 下 几 个 角色 : 


@ Subject (目标 ) : 目标 又 称 为 主题 ， 它 是 指 被 观察 的 对 象 。 在 目标 中 定义 了 一 个 观察 者 集 
合 ， 一 个 观察 目 标 可 以 接受 任意 数量 的 观察 者 来 观察 ， 它 提供 一 系列 方法 来 增加 和 删除 观察 
者 对 象 ， 同 时 它 定 义 了 通知 方法 notify0。 目 标 类 可 以 是 接口 ， 也 可 以 是 抽象 类 或 具体 类 。 


e ConcreteSubject (具体 目标 ) : 具体 目标 是 目标 类 的 子 类 ， 通 常 它 包含 有 经 常 发 生 改 变 的 数 
据 ， 当 它 的 状态 发 生 改 变 时 ， 向 它 的 各 个 观察 者 发 出 通知 ; 同时 它 还 实现 了 在 目标 类 中 定义 
的 抽象 业务 逻辑 方法 (如果 有 的 话 ) 。 如 果 无 须 扩 展 目 标 类 ， 则 具体 目标 类 可 以 省 略 。 


e@ Observer (观察 者 ) : 观察 者 将 对 观察 目标 的 改变 做 出 反应 ， 观 察 者 一 般 定 义 为 接口 ， 该 接 
口 声明 了 更 新 数据 的 方法 update()， 因 此 又 称 为 抽象 观察 者 。 


e@ ConcreteObserver (具体 观察 者 ) : 在 具体 观察 者 中 维护 一 个 指向 具体 目标 对 象 的 引用 ， 它 
存储 具体 观察 者 的 有 关 状 态 ， 这 些 状态 需要 和 具体 目标 的 状态 保持 一 致 ; 它 实现 了 在 抽象 观 
察 者 Observer 中 0 。 通常 在 实现 时 ， 可 以 调用 具体 目标 类 的 attach() 方 法 将 自 
己 添加 到 目标 类 的 集合 中 或 通过 detach() 方 法 将 自己 从 目标 类 的 集合 中 删除 。 


观察 者 模式 描述 了 如 何 建立 对 象 与 对 象 之 间 的 依赖 关系 ， 以 及 如 何 构 造 满足 这 种 需求 的 系 
统 。 观 察 者 模式 包含 观察 目标 和 观察 者 两 类 对 象 ， 一 个 目标 可 以 有 任意 数目 的 与 之 相依 赖 的 
观察 者 ， 一 旦 观察 目标 的 状态 发 生 改 变 ， 所 有 的 观察 者 都 将 得 到 通知 。 作 为 对 这 个 通知 的 响 
应 ， 每 个 观察 者 都 将 监视 观察 目标 的 状态 以 使 其 状态 与 目标 状态 同步 ， 这 种 交互 也 称 为 发 布 - 
订阅 (Publish-Subscribe)。 观察 目标 是 通知 的 发 布 者 ， 它 发 出 通知 时 并 不 0 观 
察 者 ， 可 以 有 任意 数目 的 观察 者 订阅 它 并 接收 通知 。 下面 通过 示意 代码 来 对 该 模式 进 
步 分 析 。 首 先 我 们 定义 一 个 抽象 目标 Subject， 典 型 代码 如 下 所 示 : 


import java,util.*， 
abstract class Subject { 
// 定 义 一 个 观察 者 集合 用 于 存储 所 有 观察 者 对 象 
protected ArrayList observers<Observer> = new ArrayList(); 


// 注 册 方法 ， 用 于 向 观察 者 集合 中 增加 一 个 观察 者 
public void attach(Observer observer) { 
observers.add(observer); 


} 
// 注 销 方 法 ， 用 于 在 观察 者 集合 中 删除 一 个 观察 者 
public void detach(Observer observer) { 
observers.remove(observer ) ; 

} 


// 声 明 抽 象 通知 方法 
public abstract void notify() ，; 


具体 目标 类 ConcreteSubject 是 实现 了 抽象 目标 类 Subject 的 一 个 具体 子 类 ， 其 典 : 
[java] view plain copy 
class ee extends Subject { 
// 实 现 通知 方法 
public void notify() { 
// 遍 历 观 察 者 集合 ， 调 用 每 一 个 观察 者 的 响应 方法 
for(Object obs:observers) { 
((Observer)obs).update(); 
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} 


抽象 观察 者 角色 一 般 定 义 为 一 个 接口 ， 通 常 只 声明 一 个 update() 方 法 ， 为 不 同 观察 者 的 更 新 
(响应 ) 行为 定义 相同 的 接口 ， 这 个 方法 在 其 子 类 中 实现 ， 不 同 的 观察 者 具有 不 同 的 响应 方 
法 。 抽 象 观 察 者 Observer 典型 代码 如 下 所 示 : 


interface Observer { 
// 声 明 响 应 方法 
public void update(); 


在 具体 观察 者 Concrete0bserver 中 实现 了 update() 方 法 ， 其 典型 代码 如 下 所 示 : 
[java] view plain copy 
class ConcreteObserver implements Observer { 
// 实 现 响 应 方法 
public void update() { 
// 具 体 响 应 代码 
} 


} 


在 有 些 更 加 复杂 的 情况 下 ， 具 体 观察 者 类 ConcreteObserver 的 update() 方 法 在 执行 时 需要 使 用 到 
具体 目标 类 ConcreteSubject 中 的 状态 (属性) ， 因 此 在 ConcreteObserver 与 ConcreteSubject 之 间 
有 时 候 还 存在 关联 或 依赖 关系 ， 在 ConcreteObserver 中 定义 一 个 ConcreteSubject 实 例 ， 通 过 该 实 
例 获取 存储 在 ConcreteSubject 中 的 状态 。 如 果 ConcreteObserver 的 update() 方 法 不 需要 使 用 到 
ConcreteSubject 中 的 状态 属性 ， 则 可 以 对 观察 者 模式 的 标准 结构 进行 简化 ， 在 具体 观察 者 
ConcreteObserver 和 具体 目标 ConcreteSubject 之 间 无 须 维持 对 象 引 用 。 如 果 在 具体 层 具 有 关联 关 
系 ， 系 统 的 扩展 性 将 受到 一 定 的 影响 ， 增 加 新 的 具体 目标 类 有 时 候 需 要 修改 原 有 观察 者 的 代 
码 ， 在 一 定 程度 上 违反 了 “ 开 闭 原则 ”， 但 是 如 果 原 有 观察 者 类 无 须 关 联 新 增 的 具体 目标 ， 则 系 
统 扩 展 性 不 受 影响 。 


思考 


观察 者 模式 是 否 符合 “ 开 闭 原则 ”? 【从 增加 具体 观察 者 和 增加 有 具体 目标 类 两 方面 考虑 。]】 
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对 象 间 的 联动 ~ 观察 者 模式 (三 ) 
对 象 间 的 联动 ”观察 者 模式 (三 ) 


23.3 完整 解决 方案 


为 了 实现 对 象 之 间 的 联动 ，Sunny 软 件 公司 开发 人 员 决 定 使 用 观察 者 模式 来 进行 多 人 联机 对 战 
游戏 的 设计 ， 其 基本 结构 如 图 22-4 所 示 : 


AllyControlCenter 
{abstract} 


# allyName : String 

# players :ArayList 
+ setAllyName (String allyName) : void + setName (String name) - void 
+ getAllyName () :String + help () - void 
+ join (Observer obs) + beAitacked (AlyControlCenter acc) : void 
+ quit(Observer obs) -voi A 

+ NotifyObserver (String name) - 

A 























- Name : String 

+ Player (String name) 

+ getName () 

+ setName (String name) 

+ help () 
+ beAttacked (AlyControlCenter acc) : void 


ConcreteAlyControlCenter 


+ ConcreteAllyControlCenter ( 
String allyName) 
+ notifyObserver (String name) : void 


‘ 
人 
0 
' 


if (I((Observer)obs).getName()equalslgnoreCase(name)) { 


((Observenobs).help() 


} 
} 





图 22-4 多 人 联机 对 战 游戏 结构 图 在 图 22-4 中 ，AllyControlCenter 充 当 目 标 类 ， 
ConcreteAllyControlCenter 充 当 具 体 目标 类 ，Observer 充 当 抽 象 观察 者 ，Player 充 当 具 体 观 察 
者 。 完 整 代码 如 下 所 示 : 


import java.util.*,; 


// 抽 象 观察 类 
interface Observer { 

public String getName(); 

public void setName(String name); 

public void help(); // 声 明 支 援 盟 友 方 法 

public void beAttacked(AllyControlCenter acc); // 声 明 遭 受 攻 击 方法 
} 


// 战 队 成 员 类 : 具体 观察 者 类 


class Player implements Observer { 
private String name; 
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} 


public Player(String name) { 
this.name = name; 


} 


public void setName(String name) { 
this.name = name; 
} 


public String getName() { 
return this.name; 
} 


// 支 援 盟友 方法 的 实现 
public void help() { 

System.out.println(" 坚 持 住 ，" + this.name + "来 救 你 1")) 
} 


// 嘲 受 攻击 方法 的 实现 ， 当 嘲 受 攻击 时 将 调用 战队 控制 中 心 类 的 通知 方法 notifyObser 

public void beAttacked(AllyControlCenter acc) { 
System.out.println(this.name + "被 攻击 1 ");，; 
acc,notifyobserver(name ) ; 


// 战 队 控制 中 心 类 : 目标 类 
abstract class AllyControlCenter { 
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protected String allyName; // 战 队 名 称 
protected ArrayList<Observer> players = new ArrayList<Observer>( 


public void setAllyName(String allyName) { 
this.allyName = allyName; 
} 


public String getAllyName() { 
return this.allyName; 
} 


// 注 册 方 法 

public void join(Observer obs) { 
System,.out,println(obs.getName() + "加 入 " + this.allyName + " 
players.add(obs); 


} 


// 注 销 方法 

public void quit(Observer obs) { 
System.out.println(obs.getName() + "退出 " + this.allyName + " 
players.remove(obs); 


} 


// 声 明 抽象 通知 方法 
public abstract void notifyObserver(String name ) ， 
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// 具 体 战 队 控制 中 心 类 : 具体 目标 类 
class ConcreteAllyControlCenter extends AllyControlCenter { 
public ConcreteAllyControlCenter(String allyName) { 
System.out.println(allyName + "战队 组 建成 功 | ")， 
System.out.printin(---------------------------- 全 
this.allyName = allyName; 


} 


// 实 现 通知 方法 
public void notifyObserver(String name) { 
System.out.println(this.allyName + "战队 紧急 通知 ， 盟 友 " + name : 
// 遍 历 观察 者 集合 ， 调 用 每 一 个 盟友 (自己 除外 ) 的 支援 方法 
for(Object obs : players) { 
if (!((Observer)obs).getName().equalsIgnoreCase(name)) { 
((Observer)obs).help(); 


} 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
// 定 义 观 察 目 标 对 象 
AllyControlCenter acc; 
acc = new ConcreteAllyControlCenter(" 人 金良 群 侠 ")， 


// 定 义 四 个 观察 者 对 象 
Observer playeri1,player2,Pplayer3,player4; 


player1 = new Player(" 杨 过 " ) ; 
acc.join(player1) ; 


player2 = new Player ("令狐冲 ")， 
acc .join(player2); 


player3 = new Player(" 张 无 辟 ") ; 
acc. join(plLayer3 ) ; 


player4 = new Player(" 段 誉 ")， 
acc.]jJoin(player4); 


// 某 成 员 遵 受 攻击 
Player1.beAttacked(acc ) ; 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 
金庸 群 侠 战 队 组 建成 功 ! 


杨过 加 入 金庸 群 侠 战 队 ! 
令狐冲 加 入 金庸 群 侠 战 队 ! 
371 


对 象 间 的 联动 一 一 观察 者 模式 (三 ) 


张 无 总 加 入 金庸 群 侠 战队 ! 

段 淮 加 入 金庸 群 侠 战 队 |! 

杨过 被 攻击 ! 

金庸 群 侠 战 队 紧 急 通知 ， 盟 友 杨 过 遭受 敌人 攻击 ! 

坚持 住 ， 令 狐 冲 来 救 你 ! 

坚持 住 ， 张 无 总 来 救 你 |! 

坚持 住 ， 段 誉 来 救 你 ! 

在 本 实例 中 ， 实 现 了 两 次 对 象 之 间 的 联动 ， 当 一 个 游戏 玩家 Player 对 象 的 beAttacked() 方 法 被 调 
用 时 ， 将 调用 AllyControlCenter 的 notifyObserver() 方 法 来 进行 处 理 ， 而 在 notifyObserver() 方 法 中 
又 将 调用 其 他 Player 对 象 的 help() 方 法 。Player 的 beAttacked() 方 法 、AllyControlCenter 的 
notifyObserver() 方 法 以 及 Player 的 help() 方 法 构成 了 一 个 联动 触发 链 ， 执 行 顺序 如 下 所 示 : 


Player.beAttacked() --> AllyControlCenter.notifyObserver() -->Player 
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22.4 JDK 对 观察 者 模式 的 支持 


观察 者 模式 在 Java 语 言 中 的 地 位 非常 重要 。 在 JDK 的 java.util 包 中 ， 提 供 了 Observable 类 以 及 
Observer 接口 ， 它 们 构成 了 JDK 对 观察 者 模式 的 支持 。 如 图 22-5 所 示 : 


- changed : boolean = false 
:Vector 








ne ed pe ne i 
ee di 
+ nolifyObservers 0 Se update (Observable Object arg) :voi 


+ notifyObservers (Object arg) :void 
:void 
:void 
:void 
:boolean 
:int 





ConcreteObserver 






+ Update (Observable o, Object arg) :void 


图 22-5 JDK 提 供 的 Observable 类 及 Observer 接口 结构 图 

(1) Observer 接口 

在 java.util.Observer 接 口中 只 声明 一 个 方法 ， 它 充当 抽象 观察 者 ， 其 方法 声明 代码 如 下 所 示 : 
void update(Observable o, Object arg) 

当 观 察 目标 的 状态 发 生变 化 时 ， 该 方法 将 会 被 调用 ， 在 Observer 的 子 类 中 将 实现 update() 方 
法 ， 即 具体 观察 者 可 以 根据 需要 具有 不 同 的 更 新 行为 。 当 调用 观察 目标 类 Observable 的 
notifyObservers() 方 法 时 ， 将 执行 观察 者 类 中 的 update() 方 法 。 

(2) Observable 类 


java.util.Observable 类 充当 观察 目标 类 ， 在 Observable 中 定义 了 一 个 向 量 Vector 来 存储 观察 者 对 
象 ， 它 所 包含 的 方法 及 说 明 见 表 22-1 : 表 22-1 Observable 类 所 包含 方法 及 说 明 


方法 名 方法 描述 Cool 
Observable0 构造 方法 ， 实 例 化 Vector 向 量 。 $1600 
dO ee se 用 于 注册 新 的 观察 者 对 象 到 向 量 中 。 $12 


9) 
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deleteObserver 用 于 删除 向 量 中 的 某 一 个 观察 者 对 象 。 $1 
(Observer 0) 
notifyObservers() 和 l ~、 六 内部 艇 二 2 昌 中 每 一 作 观 窑 
, , 通知 方法 ， 用 于 在 方法 内 部 循环 调用 向 量 中 每 一 个 观察 者 的 
notifyObservers(Object Ss 
update() 方 法 。 
arg) 
deleteObservers() 用 于 清空 向 量 ， 即 删除 向 量 中 所 有 观察 者 对 象 。 
ered 该 方法 被 调用 后 会 设置 一 个 boolean 类 型 的 内 部 标记 变量 changed 
的 值 为 true， 表 示 观 察 目标 对 象 的 状态 发 生 了 变化 。 
用 于 将 changed 变 量 的 值 设 为 false， 表 示 对 象 状态 不 再 发 生 改 变 
clearChanged0) 或 者 已 经 通知 了 所 有 的 观察 者 对 象 ， 调 用 了 它们 的 update() 方 
法 。 
hasChanged() 用 于 测试 对 象 状态 是 否 改变 。 
countObservers() 用 于 返回 向 量 中 观察 者 的 数量 。 


我 们 可 以 直接 使 用 Observer 接口 和 Observable 类 来 作为 观察 者 模式 的 抽象 层 ， 再 自 定 义 具 体 观 
察 者 类 和 具体 观察 目标 类 ， 通 过 使 用 JDK 中 的 Observer 接口 和 Observable 类 ， 可 以 更 加 方便 地 
在 Java 语 言 中 应 用 观察 者 模式 。 
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22.5 观察 者 模式 与 Java 事 件 处 理 


JDK 1.0 及 更 早 版 本 的 事件 模型 基于 职责 链 模式 ， 但 是 这 种 模型 不 适用 于 复杂 的 系统 ， 因 此 在 
JDK 1.1 及 以 后 的 各 个 版 本 中 ， 事 件 处 理 模型 采用 基于 观察 者 模式 的 委派 事件 模型 
(DelegationEvent Model, DEM)， 即 一 个 Java 组 件 所 引发 的 事件 并 不 由 引发 事件 的 对 象 自己 来 负 
责 处 理 ， 而 是 委派 给 独立 的 事件 处 理 对 象 负责 。 


在 DEM 模 型 中 ， 目 标 角 色 《〈 如 界面 组 件 ) 负责 发 布 事件 ， 而 观察 者 角色 (事件 处 理 者 ) 可 以 
向 目标 订阅 它 所 感 兴趣 的 事件 。 当 一 个 具体 目标 产生 一 个 事件 时 ， 它 将 通知 所 有 订阅 者 。 事 
件 的 发 布 者 称 为 事件 源 (Event Source)， 而 订阅 者 称 为 事件 监听 器 (Event Listener)， 在 这 个 过 程 
中 还 可 以 通过 事件 对 象 (Event Object) 来 传递 与 事件 相关 的 信息 ， 可 以 在 事件 监听 者 的 实现 类 中 
实现 事件 处 理 ， 因 此 事件 监听 对 象 又 可 以 称 为 事件 处 理 对 象 。 事 件 源 对 象 、 事 件 监听 对 象 

(事件 处 理 对 象 ) 和 事件 对 象 构 成 了 Java 事 件 处 理 模 型 的 三 要 素 。 事 件 源 对 象 充 当 观 察 目标 ， 
而 事件 监听 对 象 充当 观察 者 。 以 按钮 点 击 事件 为 例 ， 其 事件 处 理 流 程 如 下 : 


(1) 如 果 用 户 在 GUI 中 单 击 一 个 按钮 ， 将 触发 一 个 事件 (如 ActionEvent 类 型 的 动作 事件 ) ， 
JVM 将 产生 一 个 相应 的 ActionEvent 类 型 的 事件 对 象 ， 在 该 事件 对 象 中 包含 了 有 关 事 件 和 事件 
源 的 信息 ， 此 时 按钮 是 事件 源 对 象 ; 


(2) 将 ActionEvent 事 件 对 象 传递 给 事件 监听 对 象 〈 事 件 处 理 对 象 ) ，JDK 提 供 了 专门 用 于 处 理 
ActionEvent 事 件 的 接口 ActionListener， 开 发 人 员 需 提供 一 个 ActionListener 的 实现 类 (如 
MyActionHandler) ， 实 现在 ActionListener 接 口中 声明 的 抽象 事件 处 理 方法 actionPerformed()， 
对 所 发 生 事件 做 出 相应 的 处 理 ; 


(3) 开发 人 员 将 ActionListener 接 口 的 实现 类 (如 MyActionHandler) 对 象 注 册 到 按钮 中 ， 可 以 通 
过 按钮 类 的 addActionListener() 方 法 来 实现 注册 ; 


(4) JVM 在 触发 事件 时 将 调用 按钮 的 fireXXX() 方 法 ， 在 该 方法 内 部 将 调用 注册 到 按钮 中 的 事件 
处 理 对 象 的 actionPerformed( 〇 方法， 实现 对 事件 的 处 理 。 


使 用 类 似 的 方法 ， 我 们 可 自 定义 GUI 组 件 ， 如 包含 两 个 文本 框 和 两 个 按钮 的 登录 组 件 
LoginBean， 可 以 采用 如 图 22-6 所 示 设 计 方案 : 
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LoginEventListener lel) 
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:void 


PP 






LoginValidatorA 


+ LoginValidatorA () 
+ validateLogin (LoginEvent event) : void 
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+ LoginValidatorA () 
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+ validateLogin (LoginEvent event) : void 
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+ validateLogin (LoginEvent event) : void 
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LoginValidatorB 
+ LoginValidatorB () 
+ validateLogin (LoginEvent event) : void 














LoginValidatorB 
+ LoginValidatorB () 
+ validateLogin (LoginEvent event) : void 






图 22-6 自 定义 登录 组 件 结构 图 【省 略 按 钮 、 文 本 框 等 界面 组 件 】 


图 22-6 中 相关 类 说 明 如 下 : 


(1) LoginEvent 是 事件 类 ， 它 用 于 封装 与 事件 有 关 的 信息 ， 它 
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它 可 以 在 目标 对 象 和 观察 者 对 象 之 间 传 递 数据 ， 在 AWT 事 件 模型 中 ， 所 有 的 自 定义 事件 类 都 
是 java.util.EventObject 的 子 类 。 


(2) LoginEventListener 充 当 抽 象 观察 者 ， 它 声明 了 事件 响应 方法 validateLogin()， 用 于 处 理事 
件 ， 该 方法 也 称 为 事件 处 理 方 法 ，validateLogin() 方 法 将 一 个 LoginEvent 类 型 的 事件 对 象 作为 参 
数 ， 用 于 传输 与 事件 相关 的 数据 ， 在 其 子 类 中 实现 该 方法 ， 实 现 具 体 的 事件 处 理 。 


(3) LoginBean 充 当 具 体 目标 类 ， 在 这 里 我 们 没有 定义 抽象 目标 类 ， 对 观察 者 模式 进行 了 一 定 的 
简化 。 在 LoginBean 中 定义 了 抽象 观察 者 LoginEventListener 类 型 的 对 象 lel 和 事件 对 象 
LoginEvent， 提 供 了 注册 方法 addLoginEventListenerO 用 于 添加 观察 者 ， 在 Java 事 件 处 理 中 ， 通 
常 使 用 的 是 一 对 一 的 观察 者 模式 ， 而 不 是 一 对 多 的 观察 者 模式 ， 也 就 是 说 ， 一 个 观察 目标 中 
只 定义 一 个 观察 者 对 象 ， 而 不 是 提供 一 个 观察 者 对 象 的 集合 。 在 LoginBean 中 还 定义 了 通知 方 
法 fireLoginEvent()， 该 方法 在 Java 事 件 处 理 模型 中 称 为 “点 火 方法 "”， 在 该 方法 内 部 实例 化 了 一 
个 事件 对 象 LoginEvent， 将 用 户 输入 的 信息 传 给 观察 者 对 象 ， 并 且 调 用 了 观察 者 对 象 的 响应 方 
法 validateLogin()。 


(4) LoginValidatorA 和 LoginValidatorB 充 当 具 体 观察 者 类 ， 它 们 实现 了 在 LoginEventListener 接 口 


中 声明 的 抽象 方法 validateLogin0， 用 于 具体 实现 事件 处 理 ， 该 方法 包含 一 个 LoginEvent 类 型 的 
参数 ， 在 LoginValidatorA 和 LoginValidatorB 类 中 可 以 针对 相同 的 事件 提供 不 同 的 实现 。 
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22.6 观察 者 模式 与 MVC 
在 当前 流行 的 MVC(Model-View-Controller) 架 构 中 也 应 用 了 观察 者 模式 ，MVC 是 一 种 架构 模 
式 ， 它 包含 三 个 角色 : 模型 (Model)， 视 图 (View) 和 控制 器 (Controller)。 其 中 模型 可 对 应 于 观察 


者 模式 中 的 观察 目标 ， 而 视图 对 应 于 观察 者 ， 控 制 器 可 充当 两 者 之 问 的 中 介 者 。 当 模型 层 的 
数据 发 生 改 变 时 ， 视 图 层 将 自动 改变 其 显示 内 容 。 如 图 22-7 所 示 : 


View 








Controller 


] 
| 


a=50 
b=30 
c=20 


Model 
图 22-7 MVC 结 构 示 意图 


在 图 22-7 中 ， 模 型 层 提供 的 数据 是 视图 层 所 观察 的 对 象 ， 在 视图 层 中 包含 两 个 用 于 显示 数据 的 
图 表 对 象 ， 一 个 是 柱状 图 ， 一 个 是 饼 状 图 ， 相 同 的 数据 拥有 不 同 的 图 表 显 示 方 式 ， 如 果 模 型 

层 的 数据 发 生 改 变 ， 两 个 图 表 对 象 将 随 之 发 生变 化 ， 这 意味 着 图 表 对 象 依 赖 模型 层 提 供 的 数 

据 对 象 ， 因 此 数据 对 象 的 任何 状态 改变 都 应 立即 通知 它们 。 同 时 ， 这 两 个 图 表 之 间 相 互 独 

立 ， 不 存在 任何 联系 ， 而 且 图 表 对 象 的 个 数 没 有 任何 限制 ， 用 户 可 以 根据 需要 再 增加 新 的 图 

表 对 和 象 ， 如 折线 图 。 在 增加 新 的 图 表 对 象 时 ， 无 须 修 改 原 有 类 库 ， 满 足 “ 开 闭 原则 ”。 


扩展 
大 家 可 以 查阅 相关 资料 对 MVC 模 式 进行 深入 学 习 ， 如 Oracle 公 司 提供 的 技术 文档 《Java 


SE Application Design With MVC》， 参 考 链接 : 
http:/www.oracle.comy/technetworlwarticles/javase/index-142890.html。 
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22.7 观察 者 模式 总 结 

观察 者 模式 是 一 种 使 用 频率 非常 高 的 设计 模式 ， 无 论 是 移动 应 用 、Web 应 用 或 者 桌面 应 用 ， 观 
察 者 模式 几乎 无 处 不 在 ， 它 为 实现 对 象 之 间 的 联动 提供 了 一 套 完整 的 解决 方案 ， 凡 是 涉及 到 
一 对 一 或 者 一 对 多 的 对 象 交互 场景 都 可 以 使 用 观察 者 模式 。 观 察 者 模式 广泛 应 用 于 各 种 编程 
语言 的 GUI 事件 处 理 的 实现 ， 在 基于 事件 的 XML 解析 技术 (如 SAX2) 以 及 Web 事 件 处 理 中 也 
都 使 用 了 观察 者 模式 。 

1. 主 要 优点 

观察 者 模式 的 主要 优点 如 下 : 


(1) 观察 者 模式 可 以 实现 表示 层 和 数据 逻辑 层 的 分 离 ， 定 义 了 稳定 人 并 抽 
象 了 更 新 接口 ， 使 得 可 以 有 各 种 各 样 不 同 的 表示 层 充 当 具 体 观察 者 角色 

(2) 观察 者 模式 在 观察 目标 和 观察 者 之 间 建 立 一 个 抽象 的 耦合 。 观 察 目标 只 需要 维持 一 个 抽象 
观察 者 的 集合 ， 无 须 了 解 其 具体 观察 者 。 由 于 观察 目标 和 观察 者 没有 紧密 地 耦合 在 一 起 ， 因 
此 它们 可 以 属于 不 同 的 抽象 化 层次 。 


G) 观察 者 模式 支持 广播 通信 ， 观 察 目标 会 向 所 有 已 注册 的 观察 者 对 象 发 送 通知 ， 简 化 了 一 对 
多 系统 设计 的 难度 。 


(4) 观察 者 模式 满足 “ 开 闭 原则 ”的 要 求 ， 增 加 新 的 具体 观察 者 无 须 修改 原 有 系统 代码 ， 在 具体 
观察 者 与 观察 目标 之 间 不 存在 关联 关系 的 情况 下 ， 增 加 新 的 观察 目标 也 很 方便 。 


2. 主 要 缺点 
观察 者 模式 的 主要 缺点 如 下 : 


(1) 如 果 一 个 观察 目标 对 象 有 很 多 直接 和 间接 观察 者 ， 将 所 有 的 观察 者 都 通知 到 会 花费 很 多 时 
间 。 


(2) 如 果 在 观察 者 和 观察 目标 之 间 存 在 循环 依赖 ， 观 察 目标 会 触发 它们 之 间 进 行 循环 调用 ， 可 
能 导致 系统 崩 演 。 


(3) 观察 者 模式 没有 相应 的 机 制 让 观察 者 知道 所 观察 的 目标 对 象 是 怎么 发 生变 化 的 ， 而 仅仅 只 
是 知道 观察 目标 发 生 了 变化 。 


3. 适 用 场景 
在 以 下 情况 下 可 以 考虑 使 用 观察 者 模式 : 


(1) 一 个 抽象 模型 有 两 个 方面 ， 其 中 一 个 方面 依赖 于 另 一 个 方面 ， 将 这 两 个 方面 封装 在 独立 的 
对 象 中 使 它们 可 以 各 自 独 立地 改变 和 复 用 。 


(2) 一 个 对 象 的 改变 将 导致 一 个 或 多 个 其 他 对 象 也 发 生 改 变 ， 而 并 不 知道 具体 有 多 少 对 象 将 发 
生 改 变 ， 也 不 知道 这 些 对 象 是 谁 。 


(3) 需要 在 系统 中 创建 一 个 触发 链 ，A 对 象 的 行为 将 影响 B 对 象 ，B 对 象 的 行为 将 影响 C 对 
象 ...... ， 可 以 使 用 观察 者 模式 创建 一 种 链 式 触发 机 制 。 


练习 


ee 票 软件 ， 该 软件 需 提 供 如 下 功能 : 当 股票 购买 者 所 
购买 的 茶 支 股票 价格 变化 幅度 达到 5% 时 ， 系 统 将 自动 发 送 通 eye 全 购买 该 
股票 的 所 有 股民 。 试 使 用 观察 者 模式 设计 并 实现 该 系统 。 
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观察 者 模式 (六 


状态 模式 -State Pattern 


状态 模式 -State Pattern 


J 2 Ss 
状态 模式 -State Pattern 
状态 模式 -State Pattern 【学习 难度 : 友 龙 龙 衣 衣 ， 使 用 频率 : 丰 丰 真 六 六 】 


e@ 状态 模式 -State Pattern 


o 处 理 对 象 的 多 种 状态 及 其 相互 转换 一 一 状态 模式 
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处 理 对 象 的 多 种 状态 及 其 相互 转换 一 状态 模 
式 (一 ) 


处 理 对 得 的 多 种 状态 及 其 相互 转换 一 状态 模 
式 (一 ) 


“人 有 悲欢离合 ， 月 有 阴 晴 圆 缺 ”>， 包 括 人 在 内 ， 很 多 事物 都 具有 多 种 状态 ， 而 且 在 不 同 状态 下 
会 具有 不 同 的 行为 ， 这 些 状 态 在 特定 条 件 下 还 将 发 生 相 互 转 换 。 就 像 水 ， 它 可 以 凝 国 成 冰 ， 
也 可 以 受热 蒸发 后 变 成 水 贡 汽 ， 水 可 以 流动 ， 冰 可 以 雕刻 ， 蒜 汽 可 以 扩散 。 我 们 可 以 用 UML 
状态 图 来 描述 H2O 的 三 种 状态 ， 如 图 1 所 示 : 






do /凝固 有 do/ 熔化 
do /蒸发 doy/ 升华 
do /流动 升温 [温度 >0 度 ]/ 焙 化 do/ 风 列 






















升温 温度 >=100 度 ]/ 升 华 








升温 [温度 >=100 计 


降温 [温度 <100 度 ]/ 液化 





呈 度 <=0 度 ]/ 北 华 





图 1 H2O 的 三 种 状态 (未 考虑 临界 点 ) 

在 软件 系统 中 ， 有 些 对 象 也 像 水 一 样 具有 多 种 状态 ， 这 些 状态 在 某 些 情况 下 能 够 相互 转换 ， 
而 且 对 象 在 不 同 的 状态 下 也 将 具有 不 同 的 行为 。 为 了 更 好 地 对 这 些 具有 多 种 状态 的 对 象 进行 
设计 ， 我 们 可 以 使 用 一 种 被 称 之 为 状态 模式 的 设计 模式 ， 本 章 我 们 将 学 习 用 于 描述 对 象 状态 
及 其 转换 的 状态 模式 。 

1. 银行 系统 中 的 账户 类 设计 

Sunny 软 件 公司 欲 为 某 银 行 开发 一 套 信 用 卡 业务 系统 ， 银 行 账户 (Accounb) 是 该 系统 的 核心 类 之 
一 ， 通 过 分 析 ，Sunny 软 件 公司 开发 人 员 发 现在 该 系统 中 ， 账 户 存在 三 种 状态 ， 且 在 不 同 状态 
下 账户 存在 不 同 的 行为 ， 具 体 说 明 如 下 : 


(1) 如 果 账 户 中 余额 大 于 等 了 0， 则 账户 的 状态 为 正常 状态 (Normal State) ， 此 时 用 户 既 可 以 向 该 
账户 存款 也 可 以 从 该 账户 取款 


(2) 如 果 账 户 中 余额 小 于 0， 并 且 大 于 -2000， 则 账户 的 状态 为 透支 状态 (Overdraft State)， 此 时 
用 户 既 可 以 向 该 账户 存款 也 可 以 从 该 账户 取款 ， 但 需要 按 天 计算 利息 ; 


(3) 如 果 账 户 中 余额 等 于 -2000， 那 么 账户 的 状态 为 受 限 状态 (Restricted State)， 此 时 用 户 只 能 向 
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该 账户 存款 ， 不 能 再 从 中 取款 ， 同 时 也 将 按 天 计算 利息 ; 
(4) 根据 余额 的 不 同 ， 以 上 三 种 状态 可 发 生 相 互 转换 。 


Sunny 软 件 公司 开发 人 员 对 银行 账户 类 进行 分 析 ， 绘 制 了 如 图 2 所 示 UML 状 态 图 : 










OverdraftState 


do /deposit 

do / withdraw 
do /computelnterest 
do / stateCheck 




















取款 [balance > -2000 and balance < 0]/ 
withdraw 


NormalState 


do / deposit 
do / withdraw 
do / stateCheck 












存款 [balance >= 0]/ deposit 





取款 [balance == -200 









取款 [balance == -2000]/ withdraw 


RestrictedState 


do / deposit 
do / computelnterest 
do / stateCheck 










存款 [balance >= 0]/ deposit 







存款 [balance > -2000 andlbalance < 0]/ 


图 2 银行 账户 状态 图 


在 图 2 中 ，NormalState 表 示 正 常 状态 ，OverdraftState 表 示 透 支 状态 ，RestrictedState 表 示 受 限 状 
态 ， 在 这 三 种 状态 下 账户 对 象 拥有 不 同 的 行为 ， 方 法 deposit(0) 用 于 存款 ，withdraw0O 用 于 取 
款 ，computeInterest(O) 用 于 计算 利息 ，stateCheckO) 用 于 在 每 一 次 执行 存款 和 取款 操作 后 根据 余 
额 来 判断 是 否 要 进行 状态 转换 并 实现 状态 转换 ， 相 同 的 方法 在 不 同 的 状态 中 可 能 会 有 不 同 的 
实现 。 为 了 实现 不 同 状态 下 对 象 的 各 种 行为 以 及 对 象 状 态 之 问 的 相互 转换 ，Sunny 软 件 公 司 开 
发 人 员 设 计 了 一 个 较为 庞大 的 账户 类 Account， 其 中 部 分 代码 如 下 所 示 : 


class Account { 
private String state; // 状 态 
private int balance; // 余 额 


// 存 款 操作 
public void deposit() { 
// 存 款 
stateCheck( ); 
} 
// 取 款 操作 
public void withdraw() { 
if (state.equalsIgnoreCase("NormalState") || state.equalsIgn 
// 取 款 
stateCheck( ); 
} 
else { 
// 取 款 受 限 
} 
} 


// 计 算 利息 操作 
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public void computeInterest() { 
if(state.equalsIgnoreCase("OverdraftState") || state.equalsI!' 
// 计 算 利息 
} 
} 


// 状 态 检 查 和 转换 操作 
public void stateCheck() { 


if (balance >= 0) { 
state = "NormalState"; 


} 
else if (balance > -2000 && balance < 0) { 
state = "OverdraftState"; 


} 
else if (balance == -2000) { 
state = "RestrictedState"; 


} 
else if (balance < -2000) { 
// 操 作 受 限 


分 析 上 述 代 码 ， 我 们 不 难 发 现存 在 如 下 几 个 问题 : 


(1) 几乎 每 个 方法 中 都 包含 状态 判断 语句 ， 以 判断 在 该 状态 下 是 否 具有 该 方法 以 及 在 特定 状态 
下 该 方法 如 何 实现 ， 导 致 代码 非常 元 长 ， 可 维护 性 较 差 ; 


(2) 拥有 一 个 较为 复杂 的 stateCheck( 〇 方法， 包含 大 量 的 if...else if...else... 语 名 用 于 进行 状态 转 
换 ， 代 码 测试 难度 较 大 ， 且 不 易于 维护 ; 


(3) 系统 扩展 性 较 差 ， 如 果 需 要 增加 一 种 新 的 状态 ， 如 冻结 状态 (Frozen State， 在 该 状态 下 既 
不 允许 存款 也 不 允许 取款 ) ， 需 要 对 原 有 代码 进行 大 量 修改 ， 扩 展 起 来 非常 麻烦 。 


为 了 解决 这 些 问题 ， 我 们 可 以 使 用 状态 模式 ， 在 状态 模式 中 ， 我 们 将 对 象 在 每 一 个 状态 下 的 


行为 和 状态 转移 语句 封装 在 一 个 个 状态 类 中 ， 通 过 这 些 状态 类 来 分 散 宛 长 的 条 件 转 移 语句 ， 
让 系统 具有 更 好 的 灵活 性 和 可 扩展 性 ， 状 态 模 式 可 以 在 一 定 程度 上 解决 上 述 问题 。 
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处 理 对 得 的 多 种 状态 及 其 相互 转换 一 状态 模 
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处 理 对 得 的 多 种 状态 及 其 相互 转换 一 状态 模 
式 (二 ) 


2 状态 模式 概述 

状态 模式 用 于 解决 系统 中 复杂 对 象 的 状态 转换 以 及 不 同 状态 下 行为 的 封装 问题 。 当 系统 中 某 
个 对 象 存在 多 个 状态 ， 这 些 状 态 之 间 可 以 进行 转换 ， 而 且 对 象 在 不 同 状态 下 行为 不 相同 时 可 
以 使 用 状态 模式 。 状 态 模式 将 一 个 对 象 的 状态 从 该 对 象 中 分 离 出 来 ， 封 装 到 专门 的 状态 类 

中 ， 使 得 对 象 状 态 可 以 灵活 变化 ， 对 于 客户 端 而 言 ， 无 须 关心 对 象 状 态 的 转换 以 及 对 象 所 处 
的 当前 状态 ， 无 论 对 于 何 种 状态 的 对 象 ， 客 户 端 都 可 以 一 致 处 理 。 

状态 模式 定义 如 下 : 


状态 模式 (State Pattern) : 允许 一 个 对 象 在 其 内 部 状态 改变 时 改变 它 的 行为 ， 对 象 看 起 来 似乎 修 
改 了 它 的 类 。 其 别名 为 状态 对 象 (Objects for States)， 状 态 模式 是 一 种 对 象 行为 型 模式 。 


在 状态 模式 中 引入 了 抽象 状态 类 和 具体 状态 类 ， 它 们 是 状态 模式 的 核心 ， 其 结构 如 图 3 所 示 : 
+ handle () 
ZY 2 


- state : State Ls state 


+ request () 
I+ setState (State state) 


















ConcreteStateA ConcreteStateB 





+ handle () + handle () 


图 3 状态 模式 结构 图 
在 状态 模式 结构 图 中 包含 如 下 几 个 角色 : 


e@ Context (环境 类 ) : 环境 类 又 称 为 上 下 文 类 ， 它 是 拥有 多 种 状态 的 对 象 。 由 于 环境 类 的 状 
态 存 在 多 样 性 且 在 不 同 状态 下 对 象 的 行为 有 所 不 同 ， 因 此 将 状态 独立 出 去 形成 单独 的 状态 
类 。 在 环境 类 中 维护 一 个 抽象 状态 类 State 的 实例 ， 这 个 实例 定义 当前 状态 ， 在 具体 实现 时 ， 
它 是 一 个 State 子 类 的 对 象 。 


e State (抽象 状态 类 ) : 它 用 于 定义 一 个 接口 以 封装 与 环境 类 的 一 个 特定 状态 相关 的 行为 ， 在 
抽象 状态 类 中 声明 了 各 种 不 同 状态 对 应 的 方法 ， 而 在 其 子 类 中 实现 类 这 些 方法 ， 由 于 不 同 状 
态 下 对 象 的 行为 可 能 不 同 ， 因 此 在 不 同 子 类 中 方法 的 实现 可 能 存在 不 同 ， 相 同 的 方法 可 以 写 
在 抽象 状态 类 中 。 
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e@ ConcreteState (具体 状态 类 ) : 它 是 抽象 状态 类 的 子 类 ， 每 一 个 子 类 实现 一 个 与 环境 类 的 一 
个 状态 相关 的 行为 ， 每 一 个 具体 状态 类 对 应 环境 的 一 个 具体 状态 ， 不 同 的 具体 状态 类 其 行为 
有 所 不 同 。 


在 状态 模式 中 ， 我 们 将 对 象 在 不 同 状态 下 的 行为 封装 到 不 同 的 状态 类 中 ， 为 了 让 系统 具有 更 
好 的 灵活 性 和 可 扩展 性 ， 同 时 对 各 状态 下 的 共有 行为 进行 封装 ， 我 们 需要 对 状态 进行 抽象 ， 
引入 了 抽象 状态 类 角色 ， 其 典型 代码 如 下 所 示 : 


abstract class State { 
// 声 明 抽 象 业 务 方法 ， 不 同 的 具体 状态 类 可 以 不 同 的 实现 
public abstract void handle( ); 

} 


在 抽象 状态 类 的 子 类 即 具 体 状 态 类 中 实现 了 在 抽象 状态 类 中 声明 的 业务 方法 ， 不 同 的 具体 状 
态 类 可 以 提供 完全 不 同 的 方法 实现 ， 在 实际 使 用 时 ， 在 一 个 状态 类 中 可 能 包含 多 个 业务 方 

法 ， 如 果 在 具体 状态 类 中 某 些 业务 方法 的 实现 完全 相同 ， 可 以 将 这 些 方法 移 至 抽象 状态 类 ， 
实现 代码 的 复 用 ， 典 型 的 具体 状态 类 代码 如 下 所 示 : 


class ConcreteState extends State { 
public void handle() { 
// 方 法 具体 实现 代码 
} 


} 


环境 类 维持 一 个 对 拍 象 状 态 类 的 引用 ， 通 过 setState0) 方 法 可 以 向 环境 类 注入 不 同 的 状态 对 象 ， 
再 在 环境 类 的 业务 方法 中 调用 状态 对 象 的 方法 ， 典 型 代码 如 下 所 示 : 


class Context { 
private State state; // 维 持 一 个 对 抽象 状态 对 象 的 引用 
private int value; // 其 他 属性 值 ， 该 属性 值 的 变化 可 能 会 导致 对 象 状态 发 生变 化 


// 设 置 状 态 对 象 
public void setState(State State) { 
this.state = state; 


} 

public void request() { 
// 其 他 代码 
state.handle(); // 调 用 状态 对 象 的 业务 方法 
// 其 他 代码 

} 


} 


环境 类 实际 上 是 站 正 拥有 状态 的 对 象 ， 我 们 只 是 将 环境 类 中 与 状态 有 关 的 代码 提取 出 来 封装 
到 专门 的 状态 类 中 。 在 状态 模式 结构 图 中 ， 环 境 类 Context 与 抽象 状态 类 State 之 间 存 在 单 向 关 
联 关 系 ， 在 Context 中 定义 了 一 个 State 对 象 。 在 实际 使 用 时 ， 它 们 之 间 可 能 存在 更 为 复杂 的 关 
系 ，State 与 Context 之 间 可 能 也 存在 依赖 或 者 关联 关系 。 


在 状态 模式 的 使 用 过 程 中 ， 一 个 对 象 的 状态 之 间 还 可 以 进行 相互 转换 ， 通 党 有 两 种 实现 状态 
转换 的 方式 : 

(1) 统一 由 环境 类 来 负责 状态 之 间 的 转换 ， 此 时 ， 环 境 类 还 充当 了 状态 管理 器 (State Manager) 角 
色 ， 在 环境 类 的 业务 方法 中 通过 对 某 些 属性 值 的 判断 实现 状态 转换 ， 还 可 以 提供 一 个 专门 的 
方法 用 于 实现 属性 判断 和 状态 转换 ， 如 下 代码 片段 所 示 : 
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public void changeState() { 
// 判 断 属性 值 ， 根 据 属 性 值 进 行 状态 转换 
if (value == 0) { 
this.setState(new ConcreteStateA( )); 


else if (value == 1) { 
this.setState(new ConcreteStateB()); 


(2) 由 具体 状态 类 来 负责 状态 之 间 的 转换 ， 可 以 在 具体 状态 类 的 业务 方法 中 判断 环境 类 的 某 些 
属性 值 再 根据 情况 为 环境 类 设置 新 的 状态 对 象 ， 实 现状 态 转换 ， 同 样 ， 也 可 以 提供 一 个 专门 
的 方法 来 负责 属性 值 的 判断 和 状态 转换 。 此 时 ， 状 态 类 与 环境 类 之 间 就 将 存在 依赖 或 关联 关 
系 ， 因 为 状态 类 需要 访问 环境 类 中 的 属性 值 ， 如 下 代码 片段 所 示 : 


public void changeState(Context ctx) { 
// 根 据 环境 对 得 中 的 属性 值 进行 状态 转换 
if (ctx.getValue() == 1) { 
ctx.setState(new ConcreteStateB()); 


} 
else if (ctx.getValue() == 2) { 
ctx.setState(new ConcreteStateC()); 


丁 


理解 两 种 状态 转换 方式 的 异同 ?了 
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处 理 对 象 的 多 种 状态 及 


式 (三 ) 


3 完整 解决 方案 


Sunny 软 件 公司 开发 人 员 使 用 状态 
系统 根据 余额 将 自动 转换 到 相应 的 状态 ， 


存款 和 取款 操作 ， 





疾 式 (三) 


模式 来 解决 账户 状态 








Account 
- state : AccountState 

- owner :String 

- balance : double 


+ Account (String owner, double init) 


+ getBalance () 

+ setBalance (double balance) 
+ setState (AccountState state) 
+ deposit (double amount) 

+ withdraw (double amount) 

+ computelnterest () 






图 4 银行 账户 结构 图 










其 相互 转换 一 一 


其 相互 转换 一 一 


AccountState 


# acc : Account 


厂 态 态 模 


状 态 模 


的 转换 问题 ， 客 户 端 只 需要 执行 简单 的 
AN 其 基本 结构 如 图 4 所 示 : 





{abstract} 





+ deposit (double amount) 
+ Withdraw (double amount) : 


[+ stateCheck () 


OverdraftState 


+ OverdraftState (AccountState state) 
+ deposit (double amount) :void 
+ withdraw (double amount) :void 
+ computelnterest () 
+ stateCheck () 







+ computelnterest () 















RestrictedState 


+ RestrictedState (AccountState state) 
+ deposit (double amount) :void 
+ withdraw (double amount) :void 
+ computelnterest () 
+ stateCheck () 















+ stateCheck () 


NormalState 


+ NormalState (Account acc) 
+ NormalState (AccountState state) 

+ deposit (double amount) : void 
+ withdraw (double amount) :void 
+ computelnterest () 















在 图 4 中 ，Account 充 当 环 境 类 角色 ， AccountState 充 抽象 状态 角色 ，NormalState、 


OverdraftState 和 RestrictedState 充 当 具 体 状 态 角 色 。 


长 ， 需 要 有 耐心 ! 


// 银 行 账户 : 环境 类 
class Account { 


private AccountState state; 
private String owner; 


// 开 户 名 


private double balance = 0; // 账 户 余额 


完整 代码 如 下 所 示 : 


// 维 持 一 个 对 抽象 状态 


温 亏 提示 : 代码 有 点 


对 象 的 引用 


public Account(String owner,double init) { 


this. owner 


= owner; 


this.balance = balance,; 
= new NormalState(this); // 设 置 初始 状态 


this. state 
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System.out.println(this.owner + "开户 ， 初始 金额 为 " + init); 
System,out,println("---------------------------------------- 
} 


public double getBalance() { 
return this.balance; 
} 


public void setBalance(double balance) { 
this.balance = balance,; 


} 


public void setState(AccountState state) { 
this.state = state; 


} 


public void deposit(double amount) { 
System.out.println(this.owner + "存款 " + amount); 
state.deposit(amount); // 调 用 状态 对 象 的 deposit() 方 法 
System.out .printLn(" 现 在 余额 为 "+ this.balance); 
System.out.println(" 现 在 帐户 状态 为 "+ this.state.getCclass().geth 
System,out,println("---------------------------------------- 
} 


public void withdraw(double amount) { 
System.out.println(this.owner + "取款 " + amount ) ; 
state.withdraw(amount); // 调 用 状态 对 象 的 withdraw() 方 法 
System.out .printLn(" 现 在 余额 为 "+ this.balance ); 
System.out.println(" 现 在 帐户 状态 为 "+ this. state.getClass().get 
System,out,println("---------------------------------------- 


} 
public void computeInterest() 
{ 
state.computeInterest(); // 调 用 状态 对 象 的 computeInterest() 方 法 
} 
} 
// 抽 象 状 态 类 


abstract class AccountState { 
protected Account acc; 
public abstract void deposit(double amount ) 
public abstract void withdraw(double amount ) ， 
public abstract void computeInterest( ) 
public abstract void stateCheck(); 


} 


// 正 常 状态 : 具体 状态 类 
class NormalState extends AccountState { 
public NormalState(Account acc) { 
this.acc = acc; 


} 
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public NormalState(AccountState state) { 
this.acc = state.acc; 
} 


public void deposit(double amount) { 
acc.setBalance(acc.getBalance() + amount); 
StateCheck( ) ; 


} 


public void withdraw(double amount) { 
acc.setBalance(acc.getBalance() - amount); 


StateCheck( ) ; 
} 
public void computeInterest() 
{ 
System.out.println(" 正 常 状态 ， 无 须 支 付 利 息 1! ")， 
} 
// 状 态 转换 


public void stateCheck() { 
if (acc.getBalance() > -2000 && acc.getBalance() <= 0) { 
acc.setState(new OverdraftState(this)); 


} 

else if (acc.getBalance() == -2000) { 
acc.setState(new RestrictedState(this ) ) ， 

} 


else if (acc.getBalance() < -2000) { 
System.out.println(" 操 作 受 限 ! ")， 
} 


} 


/ /透支 状态 : 具体 状态 类 
class OverdraftState extends AccountState 
{ 
public OverdraftState(AccountState state) { 
this.acc = state.acc,; 
} 


public void deposit(double amount) { 
acc.setBalance(acc.getBalance() + amount); 
StateCheck( ) ; 


} 


public void withdraw(double amount) { 
acc.setBalance(acc.getBalance() - amount); 
stateCheck( ); 


} 


public void computeInterest() { 
System.out.println(" 计 算 利 息 1! ")， 
} 
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// 状 态 转换 
public void stateCheck() { 
if (acc.getBalance() > 0) { 
acc.setState(new NormalState(this)); 


} 

else if (acc.getBalance() == -2000) { 
acc.setState(new RestrictedSstate(this)); 

} 


else if (acc.getBalance() < -2000) { 
System.out.println(" 操 作 受 限 |! ")， 
} 


} 


// 受 限 状 态 : 具体 状态 类 
class RestrictedState extends AccountState { 
public RestrictedState(AccountState state) { 
this.acc = state.acc; 
} 


public void deposit(double amount) { 
acc.setBalance(acc.getBalance() + amount); 
StateCheck( ) ; 


} 


public void withdraw(double amount) { 
System.out.println(" 帐 号 受 限 ， 取 款 失败 ")， 
} 


public void computeInterest() { 
System.out.println(" 计 算 利 息 1! ")， 
} 


// 状 态 转换 
public void stateCheck() { 
if(acc.getBalance() > 0) { 
acc.setState(new NormalState(this)); 


else if(acc.getBalance() > -2000) { 
acc.setState(new OverdraftState(this)); 
} 


} 
编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
Account acc = new Account ("上段 誉 ", 0.0)， 
acc,deposit(1000 ) ; 
acc,wWithdraw(2000 ) 
acc,deposit(3000 ) ; 
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acc.wWithdraw(4000 ) 
acc .withdraw(1000); 
acc.computeInterest(); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


段 誉 开户 ， 初 始 金额 为 0.0 

段 誉 存款 1000.0 

现在 余额 为 1000 .0 

现在 帐户 状态 为 NormalState 

段 蕉 取款 2000 .0 

现在 余额 为 -1000.0 

现在 帐户 状态 为 OverdraftState 
段 誉 存款 3000.0 

现在 余额 为 2000.0 

现在 帐户 状态 为 NormalState 

段 蕉 取款 4000 .0 

现在 余额 为 -2000.0 

现在 帐户 状态 为 RestrictedState 
段 誉 取款 1000 .0 

帐号 受 限 ， 取 款 失 败 

现在 余额 为 -2000.0 

现在 帐户 状态 为 RestrictedState 
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4 共享 状态 


其 相互 转换 一 一 状态 模 
其 相互 转换 一 一 状态 模 


在 有 些 情况 下 ， 多 个 环境 对 象 可 能 需要 共享 同一 个 状态 ， 如 果 项 望 在 系统 中 实现 多 个 环境 对 
象 共享 一 个 或 多 个 状态 对 象 ， 那 么 需要 将 这 些 状态 对 象 定义 为 环境 类 的 静态 成 员 对 象 。 


下 面 通过 一 个 简单 实例 来 说 明 如 何 实现 共享 状态 : 


如 果菜 系统 要 求 两 个 开关 对 象 要 么 都 处 于 开 的 状态 ， 要 么 都 处 于 关 的 状态 ， 在 使 用 时 它们 的 
状态 必须 保持 一 致 ， 开 关 可 以 由 开 转 换 到 关 ， 也 可 以 由 关 转 换 到 开 。 


可 以 使 用 状态 模式 来 实现 开关 的 设计 ， 其 结构 如 图 5 所 示 : 





图 5 开关 及 其 状态 设计 结构 图 


开关 类 Switch 代码 如 下 所 示 : 


class Switch { 


private static State state,onState,offState; 


private String name; 


public Switch(String name) { 
this.name = name; 
onState = new OnState( ); 
offState = new OffState( ); 
this.state = onState,; 
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public void setState(State state) { 
this.state = state; 
} 


public static State getState(String type) { 
If (type.equalsIgnoreCase("on")) { 
return onState,; 


} 
else { 
return offState; 
} 
} 
// 打 开 开 关 


public void on() { 
System.out.print(name); 
state.on(this); 


} 


// 关 闭 开 关 
public void off( ) { 
System.out.print(name); 
state.off(this); 


} 
抽象 状态 类 如 下 代码 所 示 : 


abstract class State { 
public abstract void on(Switch s); 
public abstract void off(Switch s); 


} 
两 个 具体 状态 类 如 下 代码 所 示 : 


// 打 开 状 态 
class OnState extends State { 
public void on(Switch s) { 
System.out.println(" 已 经 打开 1! ")， 
} 


public void off(Switch s) { 
System.out.println(" 关 闭 ! ")， 
s.setState(Switch.getState("off")); 


} 


// 关 闭 状态 
class OffState extends State { 
public void on(Switch s) { 
System.out.println(" 打 开 !"); 
s.setSstate(Switch.getState("on")); 
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public void off(Switch S) { 
System.out.println(" 已 经 关闭 ! ")，; 
} 


} 
编写 如 下 客户 端 代码 进行 测试 : 


class Client { 
public static void main(String args[]) { 
Switch s1,s2; 
sil=new Switch(" 开 关 1")， 
s2=new Switch(" 开 关 2")， 


s1i.on(); 
s2.0n(); 
s1.off(); 
s2.0off(); 
s2.0n(); 
s1.on(); 


} 
输出 结果 如 下 : 


开关 1 已 经 打开 ! 
开关 2 已 经 打开 ! 
开关 1 关闭 1 
开关 2 已 经 关闭 1! 
开关 2 打开 ! 
开关 1 已 经 打开 ! 


从 输出 结果 可 以 得 知 两 个 开关 共享 相同 的 状态 ， 如 果 第 一 个 开关 关闭 ， 则 第 二 个 开关 也 将 关 
闭 ， 再 次 关闭 时 将 输出 “已 经 关闭 ”; 打开 时 也 将 得 到 类 似 结果 。 
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处 理 对 象 的 多 种 状态 及 其 相互 转换 一 一 状态 模 
式 (五 ) 


处 理 对 象 的 乡 种 状态 及 其 相互 转换 一 一 状态 模 
式 (五 ) 


5 使 用 环境 类 实现 状态 转换 


在 状态 模式 中 实现 状态 转换 时 ， 具 体 状 态 类 可 通过 调用 环境 类 Context 的 setState() 方 法 进行 状态 
的 转换 操作 ， 也 可 以 统一 由 环境 类 Context 来 实现 状态 的 转换 。 此 时 ， 增 加 新 的 具体 状态 类 可 
能 需要 修改 其 他 具体 状态 类 或 者 环境 类 的 源 代码 ， 否 则 系统 无 法 转换 到 新 增 状态 。 但 是 对 于 
客户 端 来 说 ， 无 须 关 心 状态 类 ， 可 以 为 环境 类 设置 默认 的 状态 类 ， 而 将 状态 的 转换 工作 交 给 
具体 状态 类 或 环境 类 来 完成 ， 具 体 的 转换 细节 对 于 客户 端 而 言 是 透明 的 。 


在 上 面 的 “银行 账户 状态 转换 ”实例 中 ， 我 们 通过 具体 状态 类 来 实现 状态 的 转换 ， 在 每 一 个 具体 
状态 类 中 都 包含 一 个 stateCheck0) 方 法 ， 在 该 方法 内 部 实现 状态 的 转换 ， 除 此 之 外 ， 我 们 还 可 
以 通过 环境 类 来 实现 状态 转换 ， 环 境 类 作为 一 个 状态 管理 器 ， 统 一 实现 各 种 状态 之 间 的 转换 
操作 。 


下 面 通过 一 个 包含 循环 状态 的 简单 实例 来 说 明 如 何 使 用 环境 类 实现 状态 转换 : 
Sunny 软 件 公司 某 开发 人 员 和 欲 开 发 一 个 屏幕 放大 镜 工 具 ， 其 具体 功能 描述 如 下 : 


用 户 单 击 “放大 镜 ” 按 钮 之 后 屏幕 将 放大 一 倍 ， 再 点 击 一 次 “放大 镜 ” 按 钮 屏幕 再 放大 一 倍 ， 第 三 
次 点 击 该 按钮 后 屏幕 将 还 原 到 默认 大 小 。 

可 以 考虑 使 用 状态 模式 来 设计 该 屏幕 放大 镜 工 具 ， 我 们 定义 三 个 屏幕 状态 类 NormalState、 
LargerState 和 LargestState 来 对 应 屏幕 的 三 种 状态 ， 分 别 是 正常 状态 、 二 倍 放大 状态 和 四 倍 放大 
状态 ， 屏 幕 类 Screen 充当 环境 类 ， 其 结构 如 图 6 所 示 : 


a 
- norma e : e 

- largerState : State {abstract} 
- largestState : State 
+ Screen () + display () : void 


+ setState (State state) : void 个 个 从 
NormalState LargestState 


+ onClick () : void 
+ display () : void + display () : void 


LargerState 
+ display () : void 






























图 6 屏幕 放大 镜 工具 结构 图 
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本 实例 核心 代码 如 下 所 示 : 


// 屏 幕 类 
class Screen { 
// 枚 举 所 有 的 状态 ，currentState 表 示 当 前 状态 
private State currentState, normalState, largerState, largestSsta 


public Screen() { 
this.normalState = new NormalState(); // 创 建 正常 状态 对 象 
this.largerstate = new LargerState(); // 创 建 二 倍 放 大 状态 对 象 
this.largestState = new LargestState(); // 创 建 四 倍 放大 状态 对 象 
this.currentState = normalState; // 设 置 初始 状态 
this.currentState.display(); 


} 


public void setState(State state) { 
this.currentState = state; 
} 


// 单 击 事件 处 理 方法 ， 封 转 了 对 状态 类 中 业务 方法 的 调用 和 状态 的 转换 
public void onCJlick() { 
if (this.currentState == normalState) { 
this.setState(largerState); 
this.currentState.display(); 


else if (this.currentState == largerState) { 
this.setState(largestState); 
this.currentState.display(); 


else if (this.currentState == largestState) { 
this.setState(normalState); 
this.currentState.display(); 


} 


// 抽 但 状态 类 
abstract class State { 
public abstract void display(); 


} 


// 正 常 状态 类 
class NormalState extends Statet{ 
public void display() { 
System,out ,printlLn(" 正 常 大 小 17")， 
} 


} 


// 二 倍 状 态 类 
class LargerState extends Statet{ 
public void display() { 
System.out.println(" 二 倍 大 小 ! ")， 
} 
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} 


// 四 倍 状态 类 
class LargestState extends Statet{ 
public void display() { 
System.out.println(" 四 倍 大 小 ! ")， 
} 


} 


在 上 述 代 码 中 ， 所 有 的 状态 转换 操作 都 由 环境 类 Screen 来 实现 ， 此 时 ， 环 境 类 充当 了 状态 管理 
器 角色 。 如 果 需 要 增加 新 的 状态 ， 例 如 “和 八 倍 状态 类 ”， 需要 修改 环境 类 ， 这 在 一 定 程度 上 违背 
了 “ 开 闭 原则 ”， 但 对 其 他 状态 类 没有 任何 影响 。 


编写 如 下 客户 端 代码 进行 测试 : 


class Client { 
public static void main(String args[]) { 
Screen Screen = new Screen(); 
screen.oncClick(); 
screen.oncClick(); 
screen.oncClick(); 


} 
输出 结果 如 下 : 
正常 大 小 | 
二 倍 大 小 ! 
四 倍 大 小 ! 
正常 大 小 | 
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处 理 对 象 的 乡 种 状态 及 其 相互 转换 一 一 状态 模 
式 (六 ) 


6 状态 模式 总 结 
状态 模式 将 一 个 对 象 在 不 同 状态 下 的 不 同行 为 封装 在 一 个 个 状态 类 中 ， 通 过 设置 不 同 的 状态 
对 象 可 以 让 环境 对 象 拥有 不 同 的 行为 ， 而 状态 转换 的 细节 对 于 客户 端 而 言 是 透明 的 ， 方 便 了 
客户 端的 使 用 。 在 实际 开发 中 ， 状 态 模式 具有 较 高 的 使 用 频率 ， 在 工作 流 和 游戏 开发 中 状态 
模式 都 得 到 了 广泛 的 应 用 ， 例 如 公文 状态 的 转换 、 游 戏 中 角色 的 升级 等 。 

1. 主要 优点 
状态 模式 的 主要 优点 如 下 : 


(D 封装 了 状态 的 转换 规则 ， 在 状态 模式 中 可 以 将 状态 的 转换 代码 封装 在 环境 类 或 者 具体 状态 
类 中 ， 可 以 对 状态 转换 代码 进行 集中 管理 ， 而 不 是 分 散在 一 个 个 业务 方法 中 。 


(2) 将 所 有 与 某 个 状态 有 关 的 行为 放 到 一 个 类 中 ， 只 需要 注入 一 个 不 同 的 状态 对 象 即 可 使 环境 
对 象 拥有 不 同 的 行为 。 


(3) 允许 状态 转换 逻辑 与 状态 对 象 合成 一 体 ， 而 不 是 提供 一 个 巨大 的 条 件 语句 块 ， 状态 模式 可 
以 让 我 们 避免 使 用 庞大 的 条 件 语句 来 将 业务 方法 和 状态 转换 代码 交织 在 一 起 。 


(4) 可 以 让 多 个 环境 对 象 共享 一 个 状态 对 象 ， 从 而 减少 系统 中 对 象 的 个 数 。 
1. 主要 缺点 
状态 模式 的 主要 缺点 如 下 : 
(1) 状态 模式 的 使 用 必然 会 增加 系统 中 类 和 对 象 的 个 数 ， 导 致 系统 运行 开销 增 大 。 


(2) 状态 模式 的 结构 与 实现 都 较为 复杂 ， 如 果 使 用 不 当 将 导致 程序 结构 和 代码 的 混乱 ， 增 加 系 
统 设 计 的 难度 。 


(3) 状态 模式 对 “ 开 闭 原则 ”的 支持 并 不 太 好 ， 增 加 新 的 状态 类 需要 修改 那些 负责 状态 转换 的 源 
代码 ， 否 则 无 法 转换 到 新 增 状态 ; 而 且 修 改 某 个 状态 类 的 行为 也 需 修改 对 应 类 的 源 代码 。 


适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 状态 模式 : 
(1) 对 象 的 行为 依赖 于 它 的 状态 〈 如 某 些 属性 值 ) ， 状 态 的 改变 将 导致 行为 的 变化 。 


(2) 在 代码 中 包含 大 量 与 对 象 状态 有 关 的 条 件 语句 ， 这 些 条 件 语句 的 出 现 ， 会 导致 代码 的 可 维 
护 性 和 灵活 性 变 差 ， 不 能 方便 地 增加 和 删除 状态 ， 并 且 导 致 客户 类 与 类 库 之 间 的 磷 合 增强 。 


练习 
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Sunny 软 件 公 司 欲 开发 一 款 纸牌 游戏 软件 ， 在 该 游戏 软件 中 用 户 角 色 有 具有 入 门 级 
(Primary)、 熟练 级 (Secondary)、 高 手 级 (Professional) 和 肖 灰 级 (Final) 四 种 等 级 ， 角 色 的 等 
级 与 其 积分 相对 应 ， 游 戏 胜利 将 增加 积分 ， 失 败 则 扣除 积分 。 入 门 级 具有 最 基本 的 游戏 
功能 play0 ， 熟 练 级 增加 了 游戏 胜利 积分 加 倍 功 能 doubleScore()， 高 手 级 在 熟练 级 基础 上 
再 增加 换 牌 功能 changeCards()， 明 灰 级 在 高 手 级 基础 上 再 增加 偷 看 他 人 的 牌 功能 
peekCards() ° 


试 使 用 状态 模式 来 设计 该 系统 。 
7 练习 
CD 分 析 如 下 代码 : 


class TestXYZ { 

int behaviour; 

//Getter and Setter 

public void handleAll() { 
if (behaviour == 0) { //do something } 
else if (behaviour == 1) { //do something } 
else if (behaviour == 2) { //do something } 
else if (behaviour == 3) { //do something } 

, Some more else if .. 


} 


为 了 提高 代码 的 扩展 性 和 健壮 性 ， 可 以 使 用 ( ) 设 计 模 式 来 进行 重 构 。 A. Visitor (访问 者 ) B. 
Facade (外 观 ) C. Memento (备忘录 ) D. State (状态 ) 


(2) 传输 门 是 传输 系统 中 的 重要 装置 。 传 输 门 具 有 Open (打开 ) 、Closed (关闭 ) 、 
Opening (正在 打开 ) 、StayOpen (保持 打开 ) 、Closing (正在 关闭 ) 五 种 状态 。 触 发 状态 的 
转换 事件 有 click、complete 和 timeout 三 种 。 事 件 与 其 相应 的 状态 转换 如 图 7 所 示 。 


Closed 
已 关闭 
WE 










complete 














Opening Closing 
正在 打开 正在 关闭 


StayOpen 
保持 打开 
= 
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图 7 传输 门 响应 事件 与 其 状态 转换 图 
试 使 用 状态 模式 对 传输 门 进 行 状态 模拟 ， 要 求 绘制 相应 的 类 图 并 编程 模拟 实现 。 
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策略 模式 -Strategy Pattern 
策略 模式 -Strategy Pattern 


策略 模式 -Strategy Pattern 【学 习 难 度 : 友 冯 闪闪 询 ， 使 用 频率 : 交友 友 克 交 】 
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算法 的 封装 与 切换 一 一 东 略 模式 (一 ) 
算法 的 封装 与 切换 一 一 东 略 模式 (一 ) 


俗话 说 : 条 条 大 路 通 罗马 。 在 很 多 情况 下 ， 实 现 某 个 目标 的 途径 不 止 一 条 ， 例 如 我 们 在 外 出 
旅游 时 可 以 选择 多 种 不 同 的 出 行 方式 ， 如 骑 自 行车 、 坐 汽车 、 坐 火车 或 者 坐 飞 机 ， 可 根据 实 
际 情况 (目的 地 、 旅 游 预算 、 旅 游 时 间 等 ) 来 选择 一 种 最 适合 的 出 行 方式 。 在 制订 旅行 计划 
时 ， 如 果 目 的 地 较 远 、 时 间 不 多 ， 但 不 差 钱 ， 可 以 选择 坐 飞机 去 旅游 ; 如 果 目 的 地 虽 远 、 但 
假期 长 、 且 需 控制 旅游 成 本 时 可 以 选择 坐 火车 或 汽车 ; 如 果 从 健康 和 环保 的 角度 考虑 ， 而 且 
有 足够 的 发 力 ， 自 行车 游 或 者 徒步 旅游 也 是 个 不 错 的 选择 ， 大 笑 。 


在 软件 开发 中 ， 我 们 也 常常 会 遇 到 类 似 的 情况 ， 实 现 茶 一 个 功能 有 多 条 途径 ， 每 一 条 途径 对 
应 一 种 算法 ， 此 时 我 们 可 以 使 用 一 种 设计 模式 来 实现 灵活 地 选择 解决 途径 ， 也 能 够 方便 地 增 
加 新 的 解决 途径 。 本 章 我 们 将 介绍 一 种 为 了 适应 前 法 灵活 性 而 产生 的 设计 模式 一 策略 模 
式 。 


24.1 电影 票 打 折 方 案 





Sunny 软 件 公司 为 某 电影 院 开发 了 一 套 影院 售票 系统 ， 在 该 系统 中 需要 为 不 同类 型 的 用 户 提供 
不 同 的 电影 票 打折 方式 ， 具 体 打 折 方 案 如 下 : 


(1) 学 生 赁 学 生 证 可 享受 票 价 8 折 优惠 ; 
(2) 年 龄 在 10 周 岁 及 以 下 的 儿童 可 享受 每 张 时 减免 10 元 的 优惠 〈 原 始 票 价 需 大 于 等 于 20 元 ) ; 


(3) 影院 VIP 用 户 除 享受 标价 半价 优惠 外 还 可 进行 积分 ， 积 分 系 计 到 一 定额 度 可 换取 电影 院 赠 


送 的 奖品 。 
该 系统 在 将 来 可 能 还 要 根据 需要 引入 新 的 打折 方式 。 


为 了 实现 上 述 电影 票 打 折 功 能 ，Sunny 软 件 公 司 开 发 人 员 设 计 了 一 个 电影 票 类 MovieTicket， 其 
核心 代码 片段 如 下 所 示 : 


// 电 影 票 类 

class MovieTicket { 
private double price; // 电 影 票 价格 
private String type; // 电 影 


类 型 


狂 


public void setPrice(double price) { 
this.price = price; 
} 


public void setType(String type) { 
this,type = type; 
} 


public double getPrice() { 
return this.calculate( ); 
} 


// 计 算 打 折 之 后 的 票 价 
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public double caleulate) { 
// 学 生 票 折 后 票 价 计算 
if(this.type.equalsIgnoreCase("student")) { 
System.out ,printLn(" 学 生 票 : ")， 
return this.price * 0.8; 


} 
// 儿 童 昧 折 后 标价 计算 
else if(this,.type.equalsIignoreCase("children") && this.price 
System.out .printLn(" 儿 童 票 :"); 
return this,price - 10; 


} 
//VIP 票 折 后 票 价 计算 
else if(this.type.equalsIignoreCase("vip")) { 
System.out.println("VIP 票 : ")， 
System.out.println(" 增 加 积分 ! ")， 
return this.price * 0.5; 


} 
else { 

return this.price; // 如 果 不 满足 任何 打折 要 求 ， 则 返回 原始 票 价 
} 


} 
编写 如 下 客户 端 测 试 代码 : 


class Client { 
public static void main(String args[]) { 
MovieTicket mt = new MovieTicket(); 
double originalPrice = 60.,0; // 原 始 票 价 
double currentPrice; // 折 后 价 


mt.setPrice(originalPrice); 
System.out.println(" 原 始 价 为 :" + originalPrice); 
System.out.println(----------------- 六 


mt.setType("student"); // 学 生 昧 

currentPrice = mt.getPrice()， 
System.out.println(" 折 后 价 为 :" + currentPrice) 
System.out.println(----------------- ) 


mt.setType("children"); // 儿 童 票 
currentPrice = mt.getPprice(); 
System.out.println(" 折 后 价 为 :" + currentPrice); 


} 
} 
编译 并 运行 程序 ， 输 出 结果 如 下 所 示 : 
原始 价 为 : 60.0 
学 生 票 : 
折 后 价 为 : 48 .0 
儿童 票 
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折 后 价 为 : 50 .0 


通过 MovieTicket 类 实现 了 电影 票 的 折 后 价 计算 ， 该 方案 解决 了 电影 票 打折 问题 ， 每 一 种 打折 
方式 都 可 以 称 为 一 种 打折 算法 ， 更 换 打 折 方 式 只 需 修 改 客户 端 代 码 中 的 参数 ， 无 须 修改 已 有 
源 代码 ， 但 该 方案 并 不 是 一 个 完美 的 解决 方案 ， 它 至 少 存在 如 下 三 个 问题 : 


(1) MovieTicket 类 的 calculate() 方 法 非常 庞大 ， 它 包含 各 种 打折 算法 的 实现 代码 ， 在 代码 中 出 现 
了 较 长 的 站 ...else... 语 句 ， 不 利于 测试 和 维护 。 


(2) 增加 新 的 打折 算法 或 者 对 原 有 打折 算法 进行 修改 时 必须 修改 MovieTicket 类 的 源 代码 ， 违 反 
了 “ 开 闭 原则 ”， 系统 的 灵活 性 和 可 扩展 性 较 差 。 


(3) 算法 的 复 用 性 差 ， 如果 在 另 一 个 系统 (如 商场 销售 管理 系统 ) 中 需要 重用 某 些 打折 算法 ， 
只 能 通过 对 源 代码 进行 复制 粘贴 来 重用 ， 无 法 单独 重用 其 中 的 某 个 或 某 些 算法 (重用 较为 麻 
烦 ) 。 


如 何 解 决 这 三 个 问题 ? 导致 产生 这 些 问题 的 主要 原因 在 于 MovieTicket 类 职责 过 重 ， 它 将 各 种 
打折 算法 都 定义 在 一 个 类 中 ， 这 既 不 便于 算法 的 重用 ， 也 不 便于 算法 的 扩展 。 因 此 我 们 需要 
对 MovieTicket 类 进行 重 构 ， 将 原本 庞大 的 MovieTicket 类 的 职责 进行 分 解 ， 将 算法 的 定义 和 使 
用 分 离 ， 这 就 是 策略 模式 所 要 解决 的 问题 ， 下 面 将 进入 策略 模式 的 学 习 。 
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24.2 策略 模式 概述 


在 策略 模式 中 ， 我 们 可 以 定义 一 些 独立 的 类 来 封装 不 同 的 算法 ， 每 一 个 类 封装 一 种 具体 的 算 
法 ， 在 这 里 ， 每 一 个 封装 算法 的 类 我 们 都 可 以 称 之 为 一 种 策略 (Strategy)， 为 了 保证 这 些 策略 
在 使 用 时 具有 一 致 性 ， 一 般 会 提供 一 个 抽象 的 策略 类 来 做 规则 的 定义 ， 而 每 种 算法 则 对 应 于 
一 个 具体 策略 类 。 


策略 模式 的 主要 目的 是 将 算法 的 定义 与 使 用 分 开 ， 也 就 是 将 算法 的 行为 和 环境 分 开 ， 将 算法 
的 定义 放 在 专门 的 策略 类 中 ， 每 一 个 策略 类 封装 了 一 种 实现 算法 ， 使 用 算法 的 环境 类 针对 抽 
象 策略 类 进行 编程 ， 符 合 “依赖 倒转 原则 ”。 在 出 现 新 的 算法 时 ， 只 需要 增加 一 个 新 的 实现 了 拍 
象 策略 类 的 具体 策略 类 即 可 。 策 略 模式 定义 如 下 : 策略 模式 (Strategy Pattern) : 定义 一 系列 算 
法 类 ， 将 每 一 个 算法 封装 起 来 ， 并 让 它们 可 以 相互 蔡 换 ， 策 略 模式 让 算法 独立 于 使 用 它 的 客 
户 而 变化 ， 也 称 为 政策 模式 (Policy)。 策 略 模式 是 一 种 对 象 行为 型 模式 。 


策略 模式 结构 并 不 复杂 ， 但 我 们 需要 理解 其 中 环境 类 Context 的 作用 ， 其 结构 如 图 24-1 所 示 : 


Strategy 
+ algorithm () 
ZN 





ConcreteStrategyB 





24-1 策略 模式 结构 图 
在 策略 模式 结构 图 中 包含 如 下 几 个 角色 : 
e@ Context (环境 类 ) : 环境 类 是 使 用 算法 的 角色 ， 它 在 解决 某 个 问题 〈 即 实现 某 个 方法 ) 时 
可 以 采用 多 种 策略 。 在 环境 类 中 维持 一 个 对 抽象 策略 类 的 引用 实例 ， 用 于 定义 所 采用 的 策 
略 o 
e@ Strategy (抽象 策略 类 ) : 它 为 所 支持 的 算法 声明 了 抽象 方法 ， 是 所 有 策略 类 的 父 类 ， 它 可 
以 是 抽象 类 或 具体 类 ， 也 可 以 是 接口 。 环 境 类 通过 抽象 策略 类 中 声明 的 方法 在 运行 时 调用 具 
体 策略 类 中 实现 的 算法 。 


@ ConcreteStrategy (具体 策略 类 ) : 它 实 现 了 在 抽象 策略 类 中 声明 的 算法 ， 在 运行 时 ， 具 体 策 
略 类 将 履 盖 在 环境 类 中 定义 的 抽象 策略 类 对 和 象 ， 使 用 一 种 具体 的 算法 实现 某 个 业务 处 理 。 


一 个 环境 类 Context 能 否 对 应 多 个 不 同 的 策略 等 级 结构 ? 如 何 设计 ? 
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策略 模式 是 一 个 比较 容易 理解 和 使 用 的 设计 模式 ， 策 略 模式 是 对 算法 的 封装 ， 它 把 算法 的 责 
任 和 算法 本 身分 割 开 ， 委 派 给 不 同 的 对 象 管 理 。 策 略 模式 通常 把 一 个 系列 的 算法 封装 到 一 系 
列 具体 策略 类 里 面 ， 作 为 抽象 策略 类 的 子 类 。 在 策略 模式 中 ， 对 环境 类 和 抽象 策略 类 的 理解 
非常 重要 ， 环 境 类 是 需要 使 用 算法 的 类 。 在 一 个 系统 中 可 以 存在 多 个 环境 类 ， 它 们 可 能 需要 
重用 一 些 相 同 的 算法 。 


在 使 用 策略 模式 时 ， 我 们 需要 将 算法 从 Context 类 中 提取 出 来 ， 首 先 应 该 创建 一 个 抽象 策略 
类 ， 其 典型 代码 如 下 所 示 : 


abstract class AbstractStrategy { 
public abstract void algorithm(); // 声 明 抽 象 算法 


} 
然后 再 将 封装 每 一 种 具体 工法 的 类 作为 该 抽象 策略 类 的 子 类 ， 如 下 代码 所 示 : 


class ConcreteStrategyA extends AbstractStrategy { 
// 算 法 的 具体 实现 
public void algorithm() { 
// 算 法 A 
} 
} 


其 他 具体 策略 类 与 之 类 似 ， 对 于 Context 类 而 言 ， 在 它 与 抽象 策略 类 之 间 建 立 一 个 关联 关系 ， 
其 典型 代码 如 下 所 示 : 


class Context { 
private AbstractStrategy strategy; // 维 持 一 个 对 抽象 策略 类 的 引用 


public void setStrategy(AbstractStrategy strategy) { 
this.strategy= strategy; 


} 


// 调 用 策略 类 中 的 算法 
public void algorithm() { 
strategy.algorithm(); 
} 
} 


在 Context 类 中 定义 一 个 AbstractStrategy 类 型 的 对 象 strategy， 通 过 注入 的 方式 在 客户 端 传 入 一 
个 具体 策略 对 象 ， 客 户 端 代 码 片 段 如 下 所 示 : 


Context context = new Context( ) 

AbstractStrategy strategy; 

strategy = new ConcreteStrategyA(); // 可 在 运行 时 指定 类 型 
context.setStrategy(strategy); 

context ,algorithm( ); 


在 客户 端 代码 中 只 需 注入 一 个 具体 策略 对 象 ， 可 以 将 具体 策略 类 类 名 存储 在 配置 文件 中 ， 通 
过 反射 来 动态 创建 具体 策略 对 象 ， 从 而 使 得 用 户 可 以 灵活 地 更 换 具 体 策略 类 ， 增 加 新 的 具体 
策略 类 也 很 方便 。 策 略 模式 提供 了 一 种 可 插入 式 (Pluggable) 算 法 的 实现 方案 。 
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24.3 完整 解决 方案 


为 了 实现 打折 算法 的 复 用 ， 并 能 够 灵活 地 向 系统 中 增加 新 的 打折 方式 ，Sunny 软 件 公司 开发 人 
员 使 用 策略 模式 对 电影 院 打折 方案 进行 重 构 ， 重 构 后 基本 结构 如 图 24-2 所 示 : 


MovieTicket 
- price : double 
- discount : Discount 
+ setPrice (double price) :void 
+ setDiscount (Discount discount) : void 
+ getPrice () : double 
























2 Discount 


+ calculate (double price) : double 
人 八 








StudentDiscount : VIPDiscount 
+ calculate (double price) : double : + calculate (double price) : double 


ChildrenDiscount 
+ calculate (double price) : double 


图 24-2 电影 票 打折 方案 结构 图 . 


在 图 24-2 中 ，MovieTicket 充 当 环境 类 角色 ，Discount 充 当 抽 人 象 策 略 角 色 ，StudentDiscount、 
ChildrenDiscount 和 VIPDiscount 充 当 具 体 策略 角色 。 完 整 代码 如 下 所 示 : 


// 电 影 票 类 : 环境 类 
class MovieTicket { 
private double price; 
private Discount discount; // 维 持 一 个 对 抽象 折扣 类 的 引用 


public void setPrice(double price) { 
this.price = price; 
} 


/V/ 注 入 一 个 折扣 类 对 象 

public void setDiscount(Discount discount) { 
this.discount = discount; 

} 


public double getPrice() { 
// 调 用 折扣 类 的 折扣 价 计算 方法 
return discount.calculate(this.price); 


} 


// 折 扣 类 : 抽象 策略 类 
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interface Discount { 
public double calculate(double price); 


} 


// 学 生 票 折扣 类 : 具体 策略 类 
class StudentDiscount implements Discount { 
public double calculate(double price) { 
System,out ,printLn(" 学 生 票 : ")， 
return price * 0.8; 


} 


// 儿 童 票 折扣 类 : 具体 策略 类 
class ChildrenDiscount implements Discount { 
public double calculate(double price) { 
System.out.println(" 儿 童 票 : "); 
return price - 10; 


} 


//VIP 会 员 票 折扣 类 : 具体 策略 类 
class VIPDiscount implements Discount { 
public double calculate(double price) { 
System,.out.println("VIP 标 : "); 
System.out.println(" 增 加 积分 ! "); 
return price * 0.5; 


} 


为 了 提高 系统 的 灵活 性 和 可 扩展 性 ， 我 们 将 具体 策略 类 的 类 名 存储 在 配置 文件 中 ， 并 通过 工 
具 类 XMLUtil 来 读 取 配 置 文件 并 反射 生成 对 象 ，XMLUtil 类 的 代码 如 下 所 示 : 


import javax.xml.parsers.*,; 

import org.w3c.dom.*,; 

import org.xml.sax.SAXException; 

import java.io.*; 

class XMLUtil { 

// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 

public static Object getBean( ) { 
try { 

// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory,newDocumentBuilder() ， 
Document doc; 
doc = builder.parse(new File("config.xml")); 


// 获 取 和 包含 类 名 的 文本 节点 

NodeList nl = doc.getElementsByTagName("className"); 
Node classNode=nl1.item(0).getFirstChild(); 

String cName=classNode.getNodeVvalue(); 


// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName(cName); 
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Object obj=c.newInstance( ) ; 
return obj 

} 

catch(Exception e) { 
e.printStackTrace( ); 
return null; 


} 
在 配置 文件 config.xml 中 存储 了 具体 策略 类 的 类 名 ， 代 码 如 下 所 示 : 


<?xml] version="1.0"?> 

<config> 
<className>StudentDiscount</className> 

</config> 


编写 如 下 客户 端 测试 代码 : 


class Client { 
public static void main(String args[]) { 
MovieTicket mt = new MovieTicket(); 
double originalPrice = 60.0; 
double currentPrice; 


mt.setPrice(originalPrice); 
System.out.println(" 原 始 价 为 :" + originalPrice); 
System,out,.println("--------------------------------- Ds 


Discount discount; 
discount = (Discount)XMLUtil.getBean(); // 读 取 配 置 文件 并 反射 生成 
mt.setDiscount(discount); // 注 入 折扣 对 象 


currentPrice = mt.getPprice(); 
System.out.println(" 折 后 价 为 :" + currentPrice); 


} 
编译 并 运行 程序 ， 输 出 结果 如 下 : 


原始 价 为 : 60 .0 
学 生 隶 : 


折 后 价 为 : 48.0 


如 果 需 要 更 换 具 体 策 略 类 ， 无 须 修 改 源 代码 ， 只 需 修 改 配置 文件 ， 例 如 将 学 生 票 改 为 儿童 
票 ， 只 需 将 存储 在 配置 文件 中 的 具体 策略 类 StudentDiscount 改 为 ChildrenDiscount， 如 下 代码 所 


示 : 


<?xml] version="1.0"?> 

<config> 
<className>CchildrenDiscount</className> 

</config> 
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重新 运行 客户 端 程序 ， 输 出 结果 如 下 : 
原始 价 为 : 60.0 


折 后 价 为 : 50.0 

如 果 需 要 增加 新 的 打折 方式 ， 原 有 代码 均 无 须 修 改 ， 只 要 增加 一 个 新 的 折扣 类 作为 抽象 折扣 
类 的 子 类 ， 实 现在 抽象 折扣 类 中 声明 的 打折 方法 ， 然 后 修改 配置 文件 ， 将 原 有 具体 折扣 类 类 
名 改 为 新 增 折 扣 类 类 名 即 可 ， 完 全 符合 “ 开 闭 原则 ”。 
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24.4 策略 模式 的 两 个 典型 应 用 

策略 模式 实用 性 强 、 扩 展 性 好 ， 在 软件 开发 中 得 以 广泛 使 用 ， 是 使 用 频率 较 高 的 设计 模式 之 
一 。 下 面 将 介绍 策略 模式 的 两 个 典型 应 用 实例 ， 一 个 来 源 于 Java SE， 一 个 来 源 于 微软 公司 推 
出 的 演示 项 目 PetShop。 


(1) Java SE 的 容器 布局 管理 就 是 策略 模式 的 一 个 经 典 应 用 实例 ， 其 基本 结构 示意 图 如 图 24-3 所 


示 


- orderinsertStrategy :IOrderSstrategy |"derinserStrategy 
+ LoadinsertStrategy () :IOrderStrategy + Insert (Orderlnfo order) : void 
AA 
OrderAsynchronous OrderSynchronous 
+ Insert (Orderlnfo order) : void + Insert (Orderlnfo order) : void . 


图 24-4 PetShop 订单 策略 类 结构 图 . 


2 IOrderStrategy 














【每 次 看 到 这 个 LayoutManager2 接 口 ， 我 都 在 想 当 时 Sun 公 司 开发 人 员 是 怎么 想 的 | 微笑 】 


在 Java SE 开 发 中 ， 用 户 需 要 对 容器 对 象 Container 中 的 成 员 对 象 如 按钮 、 文 本 框 等 GUI 控件 进行 
布局 (Layout)， 在 程序 运行 期 间 由 客户 端 动态 决定 一 个 Container 对 象 如 何 布 局 ，jJava 语 言 在 
JDK 中 提供 了 几 种 不 同 的 布局 方式 ， 封 装 在 不 同 的 类 中 ， 如 BorderLayout、FlowLayout、 
GridLayout、GridBagLayout 和 CardLayout 等 。 在 图 24-3 中 ，Container 类 充当 环境 角色 Context ， 
而 LayoutManager 作 为 所 有 布局 类 的 公共 父 类 扮演 了 抽象 策略 角色 ， 它 给 出 所 有 具体 布局 类 所 
需 的 接口 ， 而 具体 策略 类 是 LayoutManager 的 子 类 ， 也 就 是 各 种 具体 的 布局 类 ， 它 们 封装 了 不 
同 的 布局 方式 。 


任何 人 都 可 以 设计 并 实现 自己 的 布局 类 ， 只 需要 将 自己 设计 的 布局 类 作为 LayoutManager 的 子 
类 就 可 以 ， 比 如 传奇 的 Borland 公 司 (现在 已 是 传说 ) 曾 在 JBuilder 中 提供 了 一 种 新 的 布局 方式 
一 XYLayout， 作 为 对 JDK 提 供 的 Layout 类 的 补充 。 对 于 客户 端 而 言 ， 只 需要 使 用 Container 类 
提供 的 setLayout() 方 法 就 可 设置 任何 具体 布局 方式 ， 无 须 关心 该 布局 的 具体 实现 。 在 JDK 中 ， 
Container 类 的 代码 片段 如 下 : 


public class Container extends Component { 


public void setLayout(LayoutManager mgr) { 
layoutMgr = mgr; 
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从 上 述 代码 可 以 看 出 ，Container 作 为 环境 类 ， 针 对 抽象 策略 类 LayoutManager 进 行 编程 ， 用 户 
在 使 用 时 ， 根 据 “ 里 氏 代 换 原则 ”， 只 需要 在 setLayout() 方 法 中 传 入 一 个 具体 布局 对 象 即 可 ， 无 
须 关心 它 的 具体 实现 。 


(2) 除了 基于 Java 语 言 的 应 用 外 ， 在 使 用 其 他 面向 对 象 技 术 开 发 的 软件 中 ， 策 略 模式 也 得 到 了 
广泛 的 应 用 。 


在 微软 公司 提供 的 演示 项 目 PetShop 4.0 中 就 使 用 策略 模式 来 处 理 同步 订单 和 异步 订单 的 问题 。 
在 PetShop 4.0 的 BLL (Business Logic Layer ， 业 务 逻 辑 层 ) 子 项 目 中 有 一 个 OrderAsynchronous 
类 和 一 个 OrderSynchronous 类 ， 它 们 都 继承 自 IOrderStrategy 接 口 ， 如 图 24-4 所 示 : 


在 图 24-4 中 ，OrderSynchronous 以 一 种 同步 的 方式 处 理 订单 ， 而 OrderAsynchronous 先 将 订单 存 
放 在 一 个 队列 中 ， 然 后 再 对 队列 里 的 订单 进行 处 理 ， 以 一 种 异步 方式 对 订单 进行 处 理 。BLL 的 
Order 类 通过 反射 机 制 从 配置 文件 中 读 取 策略 配置 的 信息 ， 以 决定 到 底 是 使 用 哪 种 订单 处 理 方 
式 。 配 置 文件 web.config 中 代码 片段 如 下 所 示 : 


用 户 只 需要 修改 配置 文件 即 可 更 改 订单 处 理 方 式 ， 提 高 了 系统 的 灵活 性 。 
24.5 策略 模式 总 结 
策略 模式 用 于 算法 的 自由 切换 和 扩展 ， 它 是 应 用 较为 广泛 的 设计 模式 之 一 。 策 略 模式 对 应 于 
解决 某 一 问题 的 一 个 算法 族 ， 允 许 用 户 从 该 算法 族 中 任 选 一 个 算法 来 解决 某 一 问题 ， 同 时 可 
以 方便 地 更 换算 法 或 者 增加 新 的 算法 。 只 要 涉及 到 算法 的 封装 、 复 用 和 切换 都 可 以 考虑 使 用 
策略 模式 。 

1. 主要 优点 
策略 模式 的 主要 优点 如 下 : 


(1) 策略 模式 提供 了 对 “ 开 闭 原则 ”的 完美 支持 ， 用 户 可 以 在 不 修改 原 有 系统 的 基础 上 选择 算法 
或 行为 ， 也 可 以 灵活 地 增加 新 的 算法 或 行为 。 


(2) 策略 模式 提供 了 管理 相关 的 算法 族 的 办 法 。 策 略 类 的 等 级 结构 定义 了 一 个 算法 或 行为 族 ， 
恰当 使 用 继承 可 以 把 公共 的 代码 移 到 抽象 策略 类 中 ， 从 而 避免 重复 的 代码 。 


(3) 策略 模式 提供 了 一 种 可 以 替换 继承 关系 的 办 法 。 如 果 不 使 用 策略 模式 ， 那 么 使 用 算法 的 环 
境 类 就 可 能 会 有 一 些 子 类 ， 每 一 个 子 类 提供 一 种 不 同 的 算法 。 但 是 ， 这 样 一 来 算法 的 使 用 就 
和 算法 本 身 混 在 一 起 ， 不 符合 “单一 职责 原则 ”， 决 定 使 用 哪 一 种 算法 的 逻辑 和 该 算法 本 身 混合 
在 一 起 ， 从 而 不 可 能 再 独立 演化 ; 而 且 使 用 继承 无 法 实现 算法 或 行为 在 程序 运行 时 的 动态 切 
换 。 

(4) 使 用 策略 模式 可 以 避免 多 重 条 件 选 择 语句 。 多 重 条 件 选 择 语句 不 易 维护 ， 它 把 采取 哪 一 种 
算法 或 行为 的 逻辑 与 算法 或 行为 本 身 的 实现 逻辑 混合 在 一 起 ， 将 它们 全 部 硬 编码 (Hard Coding) 
在 一 个 庞大 的 多 重 条 件 选 择 语句 中 ， 比 直接 继承 环境 类 的 办 法 还 要 原始 和 落后 。 


(5) 策略 模式 提供 了 一 种 算法 的 复 用 机 制 ， 由 于 将 算法 单独 提取 出 来 封装 在 策略 类 中 ， 因 此 不 
同 的 环境 类 可 以 方便 地 复 用 这 些 策略 类 。 


1. 主要 缺点 
策略 模式 的 主要 缺点 如 下 : 
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(1) 客户 端 必须 知道 所 有 的 策略 类 ， 并 自行 决定 使 用 哪 一 个 策略 类 。 这 就 意味 着 客户 端 必须 理 
解 这 些 算 法 的 区 别 ， 以 便 适 时 选择 恰当 的 算法 。 换 言 之 ， 策 略 模式 只 适用 于 客户 端 知 道 所 有 
的 算法 或 行为 的 情况 。 


(2) 策略 模式 将 造成 系统 产生 很 多 具体 策略 类 ， 任 何 细小 的 变化 都 将 导致 系统 要 增加 一 个 新 的 
具体 策略 类 。 


(3) 无 法 同时 在 客户 端 使 用 多 个 策略 类 ， 也 就 是 说 ， 在 使 用 策略 模式 时 ， 客 户 端 每 次 只 能 使 用 
一 个 策略 类 ， 不 支持 使 用 一 个 策略 类 完成 部 分 功能 后 再 使 用 另 一 个 策略 类 来 完成 剩余 功能 的 
情况 。 

1. 适用 场景 
在 以 下 情况 下 可 以 考虑 使 用 策略 模式 : 
(1) 一 个 系统 需要 动态 地 在 几 种 算法 中 选择 一 种 ， 那 么 可 以 将 这 些 算法 封装 到 一 个 个 的 具体 算 
法 类 中 ， 而 这 些 具体 算法 类 都 是 一 个 抽象 算法 类 的 子 类 。 换 言 之 ， 这 些 具 体 算 法 类 均 有 统一 
的 接口 ， 根 据 “ 里 反 代 换 原 则 ”和 面向 对 象 的 多 态 性 ， 客 户 端 可 以 选择 使 用 任何 一 个 具体 算法 
类 ， 并 只 需要 维持 一 个 数据 类 型 是 抽象 算法 类 的 对 象 。 
(2) 一 个 对 象 有 很 多 的 行为 ， 如 果 不 用 恰当 的 模式 ， 这 些 行为 就 只 好 使 用 多 重 条 件 选择 语句 来 
实现 。 此 时 ， 使 用 策略 模式 ， 把 这 些 行为 转移 到 相应 的 具体 策略 类 里 面 ， 就 可 以 避免 使 用 难 
以 维护 的 多 重 条 件 选 择 语句 。 


(3) 不 希望 客户 端 知道 复杂 的 、 与 算法 相关 的 数据 结构 ， 在 具体 策略 类 中 封装 算法 与 相关 的 数 
据 结构 ， 可 以 提高 算法 的 保密 性 与 安全 性 。 


练习 


Sunny 软 件 公司 欲 开 发 一 款 飞机 模拟 系统 ， 该 系统 主要 模拟 不 同 种 类 飞机 的 飞行 特征 与 起 飞 特 
征 ， 需 要 模拟 的 飞机 种 类 及 其 特征 如 表 24-1 所 示 : 


表 24-1 飞机 种 类 及 特征 一 览 


飞机 种 类 起 飞 特 征 飞行 特征 
直升机 (Helicopter) 垂直 起 飞 (VerticalTakeOf) 亚 音 速 飞行 (SubSonicFly) 
客机 (AirPlane) 长 距离 起 飞 (LongDistanceTakeOff) 亚 音 速 飞 行 (SubSonicFly) 


歼击机 (Fighter) 长 距离 起 飞 (LongDistanceTakeOff) 超 音 速 飞 行 (SuperSonicFly) 
驶 式 战斗 机 (Harrier) ”垂直 起 飞 (VerticalTakeOff) ” 超 音 速 飞 行 (SuperSonicFly) 


为 将 来 能 够 模拟 更 多 种 类 的 飞机 ， 试 采用 策略 模式 设计 该 飞机 模拟 系统 。 
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1. 模板 方法 模式 概述 


) 
) 


在 现实 生活 中 ， 很 多 事情 都 包含 几 个 实现 步 又， 例如 请 客 吃饭 ， 无 论 吃 什么 ， 一 般 都 包含 点 
单 、 吃 东西 、 买 单 等 几 个 步骤 ， 通 常情 况 下 这 几 个 步骤 的 次 序 是 : 点 单 -> 吃 东 西 --> 买单 。 


在 这 三 个 步骤 中 ， 点 单 和 买单 大 同 小 异 ， 最 大 的 区 别 在 于 第 二 步 — 吃 什么 ? 吃 面 条 和 吃 满 
汉 全 席 可 大 不 相同 ， 如 图 1 所 示 : 





只 到 





图 1 请 客 吃饭 示意 图 


在 软件 开发 中 ， 有 时 也 会 遇 到 类 似 的 情况 ， 某 个 方法 的 实现 需要 多 个 步骤 ( 类似“ 请 客 ") ， 其 
中 有 些 步 又 是 国定 的 〔 类 似 "点 单 * 和 "买单 ") ， 而 有 些 步骤 并 不 国定 ， 存 在 可 变性 (类似 < 吃 
东西 >) 。 为 了 提高 代码 的 复 用 性 和 系统 的 灵活 性 ， 可 以 使 用 一 种 称 之 为 模板 方法 模式 的 设计 
模式 来 对 这 类 情况 进行 设计 ， 在 模板 方法 模式 中 ， 将 实现 功能 的 每 一 个 步骤 所 对 应 的 方法 称 
为 基本 方法 (例如 “点 单 *、“ 吃 东西 "和 “买单 *) ， 而 调用 这 些 基 本 方法 同时 定义 基本 方法 的 执 
行 次 序 的 方法 称 为 模板 方法 (例如 “请 客 ") 。 在 模板 方法 模式 中 ， 可 以 将 相同 的 代码 放 在 父 类 
中 ， 例 如 将 模板 方法 “请 客 "以 及 基本 方法 "点 单 * 和 "买单 "的 实现 放 在 父 类 中 ， 而 对 于 基本 方 
法 < 吃 东西 *， 在 父 类 中 只 做 一 个 声明 ， 将 其 具体 实现 放 在 不 同 的 子 类 中 ， 在 一 个 子 类 中 提 
供 “ 吃 面条 ”的 实现 ， 而 另 一 个 子 类 提供 “ 吃 满汉全席 * 的 实现 。 通 过 使 用 模板 方法 模式 ， 一 方面 
提高 了 代码 的 复 用 性 ， 另 一 方面 还 可 以 利用 面向 对 象 的 多 态 性 ， 在 运行 时 选择 一 种 具体 子 

类 ， 实 现 完整 的 < 请客" 方法， 提高 系统 的 灵活 性 和 可 扩展 性 。 


模板 方法 模式 定义 如 下 : 
模板 方法 模式 : 定义 一 个 操作 中 算法 的 框架 ， 而 将 一 些 步骤 延迟 到 子 类 中 。 模 板 方法 模 
式 使 得 子 类 可 以 不 改变 一 个 算法 的 结构 即 可 重 定义 该 算法 的 某 些 特定 步骤 。 


Template Method Pattern: Define the skeleton of an algorithm in an operation, deferring some 
steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm 
without changing the algorithm's structure. 
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模板 方法 模式 是 一 种 基于 继承 的 代码 复 用 技术 ， 它 是 一 种 类 行为 型 模式 。 

模板 方法 模式 是 结构 最 简单 的 行为 型 设计 模式 ， 在 其 结构 中 只 存在 父 类 与 子 类 之 间 的 继承 关 
系 。 通 过 使 用 模板 方法 模式 ， 可 以 将 一 些 复杂 流程 的 实现 步骤 封装 在 一 系列 基本 方法 中 ， 在 
抽象 父 类 中 提供 一 个 称 之 为 模板 方法 的 方法 来 定义 这 些 基 本 方法 的 执行 次 序 ， 而 通过 其 子 类 
来 覆盖 某 些 步骤 ， 从 而 使 得 相同 的 算法 框架 可 以 有 不 同 的 执行 结果 。 模 板 方法 模式 提供 了 一 
个 模板 方法 来 定义 算法 框架 ， 而 某 些 具体 步骤 的 实现 可 以 在 其 子 类 中 完成 。 

1. 模板 方法 模式 结构 与 实现 
2.1 模式 结构 


模板 方法 模式 结构 比较 简单 ， 其 核心 是 抽象 类 和 其 中 的 模板 方法 的 设计 ， 其 结构 如 图 2 所 示 : 


AbstractClass 
{abstract} 
+ TemplateMethod () 
+ PrimitiveOperation1 () 


+ PrimitiveOperation2 () 
+ PrimitiveOperation3 () 
A 









PrimitveOperation1(); 
PrimitveOperation2(); 


PrimitveOperation3(); 





ConcreteClass 


+ PrimitiveOperation1 () 
+ PrimitiveOperation2 () 


图 2 模板 方法 模式 结构 图 

由 图 2 可 知 ， 模 板 方法 模式 包含 如 下 两 个 角色 : 

(1) AbstractClass (抽象 类 ) : 在 抽象 类 中 定义 了 一 系列 基本 操作 (PrimitiveOperations)， 这 些 基 
本 操作 可 以 是 具体 的 ， 也 可 以 是 抽象 的 ， 每 一 个 基本 操作 对 应 工法 的 一 个 步骤 ， 在 其 子 类 中 
可 以 重 定义 或 实现 这 些 步 又。 同时 ， 在 抽象 类 中 实现 了 一 个 模板 方法 (Template Method)， 用 于 


定义 一 个 算法 的 框架 ， 模 板 方法 不 仅 可 以 调用 在 抽象 类 中 实现 的 基本 方法 ， 也 可 以 调用 在 抽 
象 类 的 子 类 中 实现 的 基本 方法 ， 还 可 以 调用 其 他 对 象 中 的 方法 。 


(2) ConcreteClass (具体 子 类 ) : 它 是 抽象 类 的 子 类 ， 用 于 实现 在 父 类 中 声明 的 抽象 基本 操作 
以 完成 子 类 特定 算法 的 步骤 ， 也 可 以 覆盖 在 父 类 中 已 经 实现 的 具体 基本 操作 。 


2.2 模式 实现 


在 实现 模板 方法 模式 时 ， 开 发 抽象 类 的 软件 设计 师 和 开发 具体 子 类 的 软件 设计 师 之 间 可 以 进 
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行 协作 。 一 个 设计 师 负 责 给 出 一 个 算法 的 轮 廊 和 框架 ， 另 一 些 设计 师 则 负责 给 出 这 个 算法 的 
各 个 逻辑 步 又。 实现 这 些 具体 逻辑 步骤 的 方法 即 为 基本 方法 ， 而 将 这 些 基 本 方法 汇总 起 来 的 
方法 即 为 模板 方法 ， 模 板 方法 模式 的 名 字 也 因此 而 来 。 下 面 将 详细 介绍 模板 方法 和 基本 方 
法 : 


1. 模板 方法 


一 个 模板 方法 是 定义 在 抽象 类 中 的 、 把 基本 操作 方法 组 合 在 一 起 形成 一 个 总 算法 或 一 个 总 行 
为 的 方法 。 这 个 模板 方法 定义 在 抽象 类 中 ， 并 由 子 类 不 加 以 修改 地 完全 继承 下 来 。 模 板 方法 
是 一 个 具体 方法 ， 它 给 出 了 一 个 顶层 逻辑 框架 ， 而 逻辑 的 组 成 步骤 在 抽象 类 中 可 以 是 具体 方 
法 ， 也 可 以 是 抽象 方法 。 由 于 模板 方法 是 具体 方法 ， 因 此 模板 方法 模式 中 的 抽象 层 只 能 是 折 
象 类 ， 而 不 是 接口 。 


1. 基本 方法 


基本 方法 是 实现 算法 各 个 步骤 的 方法 ， 是 模板 方法 的 组 成 部 分 。 基 本 方法 又 可 以 分 为 三 种 : 
抽象 方法 (Abstract Method)、 具 体 方法 (Concrete Method) 和 钧 子 方法 (Hook Method)。 


(1) 抽象 方法 : 一 个 抽象 方法 由 抽象 类 声明 、 由 其 具体 子 类 实现 。 在 C# 语 言 里 一 个 抽象 方法 以 
abstract 关 键 字 标识 。 


(2) 具体 方法 : 一 个 具体 方法 由 一 个 抽象 类 或 具体 类 声明 并 实现 ， 其 子 类 可 以 进行 覆盖 也 可 以 
直接 继承 。 


(3) 钩子 方法 : 一 个 钧 子 方法 由 一 个 抽象 类 或 具体 类 声明 并 实现 ， 而 其 子 类 可 能 会 加 以 扩展 。 
通常 在 父 类 中 给 出 的 实现 是 一 个 空 实现 (可 使 用 virtual 关 键 字 将 其 定义 为 虚 函 数 ) ， 并 以 该 空 
实现 作为 方法 的 默认 实现 ， 当 然 钧 子 方法 也 可 以 提供 一 个 非 空 的 默认 实现 。 


在 模板 方法 模式 中 ， 钧 子 方法 有 两 类 : 第 一 类 钧 子 方法 可 以 与 一 些 具体 步骤 “挂钩 ”， 以 实现 在 
不 同 条 件 下 执行 模板 方法 中 的 不 同步 又 ， 这 类 钩子 方法 的 返回 类 型 通常 是 bool 类 型 的 ， 这 类 方 
法 名 一 般 为 ISXXX(0O， 用 于 对 某 个 条 件 进 行 判断 ， 如 果 条 件 满足 则 执行 某 一 步 又， 否则 将 不 执 
行 ， 如 下 代码 片段 所 示 : 


// 模 板 方法 

public void TemplateMethod() 
{ 

Open( ); 

Display(); 

// 通 过 钧 子 方法 来 确定 某 步 骤 是 否 执行 
If (IsPrint()) 


Print(); 


} 


// 钓 子 方法 
public bool IsPrint() 
{ 


return true,; 


在 代码 中 IsPrint(O) 方 法 即 是 钧 子 方法 ， 它 可 以 决定 Print() 方 法 是 否 执行 ， 一 般 情 况 下 ， 钧 子 方 
法 的 返回 值 为 true， 如 果 不 希 望 某 方法 执行 ， 可 以 在 其 子 类 中 禾 盖 钩子 方 法 ， 将 其 返回 值 改 为 
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false 即 可 ， 这 种 类 型 的 钧 子 方法 可 以 控制 方法 的 执行 ， 对 一 个 算法 进行 约束 。 


还 有 一 类 钧 子 方法 就 是 实现 体 为 空 的 具体 方法 ， 子 类 可 以 根据 需要 履 盖 或 者 继承 这 些 钧 子 方 
法 ， 与 抽象 方法 相 比 ， 这 类 钧 子 方法 的 好 处 在 于 子 类 如 果 没 有 履 盖 父 类 中 定义 的 钧 子 方法 ， 
编译 可 以 正常 通过 ， 但 是 如 果 没 有 履 盖 父 类 中 声明 的 抽象 方法 ， 编 译 将 报错 。 


在 模板 方法 模式 中 ， 抽 象 类 的 典型 代码 如 下 : 
abstract class AbstractClass 


{ 

// 模 板 方法 

public void TemplateMethod() 
{ 


Primitiveoperation1( ) ， 
PrimitiveOperation2(); 
PrimitiveOperation3(); 


} 


// 基 本 方法 -具体 方法 
public void Primitiveoperationl1( ) 


/7 实现 代码 
} 


// 基 本 方法 -抽象 方法 
public abstract void PrimitiveOperation2(); 


// 基 本 方法 -钩子 方法 

public virtual void PrimitiveOperation3() 
{ } 

} 


在 抽象 类 中 ， 模 板 方法 TemplateMethod() 定 义 了 算法 的 框架 ， 在 模板 方法 中 调用 基本 方法 以 实 
现 完整 的 算法 ， 每 一 个 基本 方法 如 PrimitiveOperation1()、PrimitiveOperation2() 等 均 实现 了 算法 
的 一 部 分 ， 对 于 所 有 子 类 都 相同 的 基本 方法 可 在 父 类 提供 具体 实现 ， 例 如 
PrimitiveOperation10， 和 否则 在 父 类 声明 为 抽象 方法 或 钩子 方法 ， 由 不 同 的 子 类 提供 不 同 的 实 
现 ， 例 如 PrimitiveOperation20 和 PrimitiveOperation30 。 


可 在 抽象 类 的 子 类 中 提供 抽象 步骤 的 实现 ， 也 可 昨 盖 父 类 中 已 经 实现 的 具体 方法 ， 具 体 子 类 
的 典型 代码 如 下 : 


class ConcreteClass : AbstractClass 


{ 


public override void PrimitiveOperation2() 


// 实 现代 码 

} 

public override void PrimitiveOperation3() 
// 实 现代 码 

} 

} 
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在 模板 方法 模式 中 ， 由 于 面向 对 象 的 多 态 性 ， 子 类 对 象 在 运行 时 将 覆盖 父 类 对 象 ， 子 类 中 定 
义 的 方法 也 将 覆盖 父 类 中 定义 的 方法 ， 因 此 程序 在 运行 时 ， 具 体 子 类 的 基本 方法 将 履 盖 父 类 
中 定义 的 基本 方法 ， 子 类 的 钓 子 方法 也 将 覆盖 父 类 的 钩子 方法 ， 从 而 可 以 通过 在 子 类 中 实现 
的 钩子 方法 对 父 类 方法 的 执行 进行 约束 ， 实 现 子 类 对 父 类 行为 的 反 向 控制 。 
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3 模板 方法 模式 应 用 实例 
下 面 通过 一 个 应 用 实例 来 进一步 学 习 和 理解 模板 方法 模式 。 
1. 实例 说 明 
某 软 件 公司 和 欲 为 某 银 行 的 业务 支撑 系统 开发 一 个 利息 计算 模块 ， 利 息 计 算 流程 如 下 : 
(1) 系统 根据 账号 和 密码 验证 用 户 信 息 ， 如 果 用 户 信息 错误 ， 系 统 显 示 出 错 提示 ; 


(2) 如 果 用 户 信息 正确 ， 则 根据 用 户 类 型 的 不 同 使 用 不 同 的 利息 计算 公式 计算 利息 〈《 如 活期 账 
户 和 定期 账户 具有 不 同 的 利息 计算 公式 ) ; 


(3) 系统 显示 利息 。 
试 使 用 模板 方法 模式 设计 该 利息 计算 模块 。 
1. 实例 类 图 


通过 分 析 ， 本 实例 结构 图 如 图 3 所 示 。 





图 3 银行 利息 计算 模块 结构 图 


在 图 3 中 ，Account 充 当 抽 象 类 角色 ，CurrentAccount 和 SavingAccount 充 当 具 体 子 类 角色 。 
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1. 实例 代码 
(1) Account : 账户 类 ， 充 当 抽 象 类 。 


//Account ,cs 
Using System 


namespace TemplateMethodSample 


{ 
abstract class Account 
// 基 本 方法 一 具体 方法 
public bool Validate(string account, string password) 
{ 
Console.WriteLine(" 账 号 : {0}"，account); 
Console.WriteLine(" 密 码 : {0}"，password); 
// 模 拟 登 录 
if (account.Equals(" 张 无 尽 ") && password.Equals("123456") 
{ 
return true,; 
} 
else 
{ 
return false; 
} 
} 
// 基 本 方法 一 抽象 方法 
public abstract void CalculateInterest() ， 
// 基 本 方法 一 具体 方法 
public void Display() 
{ 
Console.WriteLine(" 显 示 利 息 ! ")， 
} 
// 模 板 方 法 
public void Handle(string account, string password) 
{ 
if (!Validate(account,password)) 
{ 
Console.WriteLine(" 账 户 或 密码 错误 | ")， 
return,; 
CalculateInterest(); 
Display( ); 
} 
} 
} 


(2) CurrentAccount : 活期 账户 类 ， 充 当 具 体 子 类 。 


//CurrentAccount.cs 
Using System; 
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namespace TemplateMethodSample 


{ 
class CurrentAccount : Account 
// 履 盖 父 类 的 抽象 基本 方法 
public override void CalculateInterest() 
{ 
Console,.WriteLine(" 按 活期 利率 计算 利息 17")， 
} 
} 
} 


(3) SavingAccount : 定期 账户 类 ， 充 当 具 体 子 类 。 


//SavingAccount.cs 
using System; 


namespace TemplateMethodSample 


{ 
class SavingAccount : Account 
// 履 盖 父 类 的 抽象 基本 方法 
public override void CalculateInterest() 
{ 
Console.WriteLine(" 按 定期 利率 计算 利息 ! ")， 
} 
} 
} 


(4) 配置 文件 App.config， 在 配置 文件 中 存储 了 具体 子 类 的 类 名 。 


<?xml1 version="1.0" encoding="utf-8" ?> 
<configuration> 
<appSettings> 
<add key="subClass" value="TemplateMethodSsample.CurrentAccount"/ 
</appSettings> 
</configuration> 


(5) Program : 客户 端 测试 类 


//Program.cs 

Using System， 

Using System.Configuration; 
Using System.Reflection,; 


namespace TemplateMethodSample 


{ 


class Program 


{ 


static void Main(string[] args) 


{ 


Account account,; 
// 读 取 配 置 文件 


424 


模板 方法 模式 深度 解析 (二 ) 


string SubClassStr = ConfigurationManager .AppSettings["SI 
// 反 射 生成 对 象 

account = (Account)Assembly.Load("TemplateMethodSample") 
account .Handle(" 张 无 总"，"123456" ) ; 

Console,Read ( ) ， 


编译 并 运行 程序 ， 输 出 结果 如 下 : 


账号 : 张无忌 
密码 : 123456 

按 活期 利率 计算 利息 | 
显示 利息 |! 


如 果 需 要 更 换 具体 子 类 ， 无 须 修改 源 代码 ， 只 需 修 改 配置 文件 App.config， 例 如 将 活期 账户 
(CurrentAccount) 改 为 定期 账户 (Saving Account)， 只 需 将 存储 在 配置 文件 中 的 具体 子 类 
CurrentAccount 改 为 SavingAccount， 如 下 代码 所 示 : 


<?xml1 version="1.0" encoding="utf-8" ?> 
<configuration> 
<appSettings> 
<add key="subClass" value="TemplateMethodSample.SavingAccount"/> 
</appSettings> 
</configuration> 


重新 运行 客户 端 程序 ， 输 出 结果 如 下 : 
账号 : 张无忌 

密码 : 123456 

按 定期 利率 计算 利息 ! 

显示 利息 | 


如 果 需 要 增加 新 的 具体 子 类 (新 的 账户 类 型 ) ， 原 有 代码 均 无 须 修改 ， 完 全 符合 开 闭 原 
风 ] O 
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4 钓 子 方法 的 使 用 


模板 方法 模式 中 ， 在 父 类 中 提供 了 一 个 定义 蓝 法 框架 的 模板 方法 ， 还 提供 了 一 系列 抽象 方 
法 、 具 体 方法 和 钧 子 方法 ， 其 中 钩子 方法 的 引入 使 得 子 类 可 以 控制 父 类 的 行为 。 最 简单 的 多 
子 方法 就 是 空 方法 ， 代 码 如 下 : 


public virtual void Display() { } 


当然 也 可 以 在 钩子 方法 中 定义 一 个 默认 的 实现 ， 如 果子 类 不 覆盖 钩子 方法 ， 则 执行 父 类 的 黑 
认 实 现代 码 。 


另 一 种 钩子 方法 可 以 实现 对 其 他 方法 进行 约束 ， 这 种 钧 子 方法 通常 返回 一 个 bool 类 型 ， 即 返回 
true 或 false， 用 来 判断 是 否 执行 某 一 个 基本 方法 ， 下 面 通 过 一 个 实例 来 说 明 这 种 钩子 方法 的 使 
用 。 


某 软 件 公司 欲 为 销售 管理 系统 提供 一 个 数据 图 表 显 示 功 能 ， 该 功能 的 实现 包括 如 下 几 个 步 
又 : 


(1) 从 数据 源 获取 数据 ; 
(2) 将 数据 转换 为 XML 格式 ; 
(3) 以 某 种 图 表 方 式 显 示 XML 格 式 的 数据 。 


该 功能 支持 多 种 数据 源 和 多 种 图 表 显 示 方 式 ， 但 所 有 的 图 表 显 示 操 作 都 基于 XML 格式 的 数 
据 ， 因 此 可 能 需要 对 数据 进行 转换 ， 如 果 从 数据 源 获取 的 数据 已 经 是 XML 数据 则 无 须 转换 。 


由 于 该 数据 图 表 显 示 功 能 的 三 个 步骤 次 序 是 国定 的 ， 且 存在 公共 代码 (例如 数据 格式 转换 代 
码 ) ， 满 足 模板 方法 模式 的 适用 条 件 ， 可 以 使 用 模板 方法 模式 对 其 进行 设计 。 因 为 数据 格式 
的 不 同 ，XMIL 数 据 可 以 直接 显示 ， 而 其 他 格式 的 数据 需要 进行 转换 ， 因 此 第 (2) 步 “将 数据 转换 
为 XML 格式 ”的 执行 存在 不 确定 性 ， 为 了 解决 这 个 问题 ， 可 以 定义 一 个 钩子 方法 
IsSNotXMLData0 来 对 数据 转换 方法 进行 控制 。 通 过 分 析 ， 该 图 表 显 示 功 能 的 基本 结构 如 图 4 所 


示 


DataViewer 
{abstract} 


XMLDataViewer 





+ GetData () : void 
+ DisplayData ()  : void 
+ lIsNotXMLData () : bool 





+ Process () 
图 4 数据 图 表 显 示 功 能 结构 图 


可 以 将 公共 方法 和 框架 代码 放 在 抽象 父 类 中 ， 代 码 如 下 : 
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//DataViewer.cs 
Using System; 


namespace TemplateMethodSample 


abstract class DataViewer 


{ 
// 抽 象 方法 : 获取 数据 
public abstract void GetData( ) ; 


// 有 具体 方法 : 转换 数据 
public void ConvertDatal( ) 


{ 


} 


// 抽 莹 方法 : 显示 数据 
public abstract void DisplayData( ); 


Console.WriteLine(" 将 数据 转换 为 XML 格式 。") ; 


// 钧 子 方法 : 判断 是 否 为 XML 格式 的 数据 
public virtual bool ISNotXMLData( ) 
{ 


} 


// 模 板 方法 
public void Process() 


{ 


return true， 


GetData( ); 

// 如 果 不 是 XML 格式 的 数据 则 进行 数据 转换 
if (ISNotXMLData( ) ) 

{ 


ConvertData( ) ; 


DisplayData( ) ; 


} 


在 上 面 的 代码 中 ， 引 入 了 一 个 钩子 方法 ISNotXMLData0， 其 返回 类 型 为 bool 类 型 ， 在 模板 方法 
中 通过 它 来 对 数据 转换 方法 ConvertData() 进 行 约束 ， 该 钧 子 方法 的 默认 返回 值 为 ttue， 在 子 类 
中 可 以 根据 实际 情况 覆盖 该 方法 ， 其 中 用 于 显示 XML 格 式 数 据 的 具体 子 类 XMLDataViewer 代 
码 如 下 : 


//XMLDataViewer.cs 
Using System， 


namespace TemplateMethodSample 


{ 


class XMLDataViewer : DataViewer 


// 实 现 父 类 方法 : 获取 数据 
public override void GetData( ) 
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{ 


} 
// 实 现 父 类 方法 : 显示 数据 ， 默 认 以 柱状 图 方式 显示 ， 可 结合 桥接 模式 来 改进 
public override void DisplayData() 


{ 


} 

// 禾 盖 父 类 的 钩子 方法 

public override bool ISNotXMLDatal ) 
{ 


} 


Console.WriteLine(" 从 XML 文件 中 获取 数据 。" ) ; 


Console.WriteLine(" 以 柱状 图 显示 数据 。")， 


return false; 


} 


在 具体 子 类 XMLDataViewer 中 履 盖 了 钧 子 方法 IsSNotXMLData0， 返 回 false， 表 示 该 数据 已 为 
XML 格式 ， 无 须 执 行 数据 转换 方法 ConvertData0， 客 户 端 代 码 如 下 : 


//Program.cs 
Using System; 


namespace TemplateMethodSample 


{ 
class Program 
{ 
static void Main(string[] args) 
DataViewer dyv; 
dv = new XMLDataViewer(); 
dv.Process(); 
Console.Read( ); 
} 
} 
} 
该 程序 运行 结果 如 下 : 


从 XML 文件 中 获取 数据 。 
以 柱状 图 显示 数据 。 


5 模板 方法 模式 效果 与 适用 场景 

模板 方法 模式 是 基于 继承 的 代码 复 用 技术 ， 它 体现 了 面向 对 象 的 诸多 重要 思想 ， 是 一 种 使 用 
较为 频繁 的 模式 。 模 板 方法 模式 广泛 应 用 于 框架 设计 中 ， 以 确保 通过 父 类 来 控制 处 理 流 程 的 
逻辑 顺序 (如 框架 的 初始 化 ， 测 试 流程 的 设置 等 ) 。 

5.1 模式 优点 

模板 方法 模式 的 主要 优点 如 下 : 

(1) 在 父 类 中 形式 化 地 定义 一 个 算法 ， 而 由 它 的 子 类 来 实现 细节 的 处 理 ， 在 子 类 实现 详细 的 处 
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理 算法 时 并 不 会 改变 算法 中 步骤 的 执行 次 序 。 

(2) 模板 方法 模式 是 一 种 代码 复 用 技术 ， 它 在 类 库 设 计 中 尤为 重要 ， 它 提取 了 类 库 中 的 公共 行 
为 ， 将 公共 行为 放 在 父 类 中 ， 而 通过 其 子 类 来 实现 不 同 的 行为 ， 它 鼓励 我 们 恰当 使 用 继承 来 
实现 代码 复 用 。 


(3) 可 实现 一 种 反 向 控制 结构 ， 通 过 子 类 履 盖 父 类 的 钩子 方法 来 决定 某 一 特定 步骤 是 否 需要 执 
行 。 


(4) 在 模板 方法 模式 中 可 以 通过 子 类 来 覆盖 父 类 的 基本 方法 ， 不 同 的 子 类 可 以 提供 基本 方法 的 
不 同 实现 ， 更 换 和 增加 新 的 子 类 很 方便 ， 符 合 单一 职责 原则 和 开 闭 原则 。 


5.2 模式 缺点 
模板 方法 模式 的 主要 缺点 如 下 : 


需要 为 每 一 个 基本 方法 的 不 同 实现 提供 一 个 子 类 ， 如 果 父 类 中 可 变 的 基本 方法 太 多 ， 将 会 叶 
致 类 的 个 数 增加 ， 系 统 更 加 庞大 ， 设 计 也 更 加 抽象 ， 此 时 ， 可 结合 桥接 模式 来 进行 设计 。 


5.3 模式 适用 场景 

在 以 下 情况 下 可 以 考虑 使 用 模板 方法 模式 : 

(1) 对 一 些 复杂 的 算法 进行 分 割 ， 将 其 算法 中 国定 不 变 的 部 分 设计 为 模板 方法 和 父 类 具体 方 
法 ， 而 一 些 可 以 改变 的 细节 由 其 子 类 来 实现 。 即 : 一 次 性 实现 一 个 算法 的 不 变 部 分 ， 并 将 可 
变 的 行为 留 给 予 类 来 实现 。 

(2) 各 子 类 中 公共 的 行为 应 被 提取 出 来 并 集中 到 一 个 公共 父 类 中 以 避免 代码 重复 。 

(3) 需要 通过 子 类 来 决定 父 类 算法 中 某 个 步骤 是 否 执行 ， 实 现 子 类 对 父 类 的 反 向 控制 。 
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~、~ ~、 a ee 
访问 者 模式 -Visitor Pattern 
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e 访问 者 模式 -Visitor Pattern 
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o 操作 复杂 对 象 结构 
o 操作 复杂 对 象 结构 
o 操 人 杂 对 象 结构 


访问 者 模式 (一 
访问 者 模式 
访问 者 模式 























访问 者 模式 (四 
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想必 大 家 都 去 过 医院 ， 虽 然 没 有 人 喜欢 去 医院 ( 爱 岗 效 业 的 医务 工作 人 员 除 外 ， 微 笑 ) 。 在 
医生 开具 处 方 单 ( 药 单 ) 后 ， 很 多 医院 都 存在 如 下 处 理 流程 : 划 价 人 员 拿 到 处 方 单 之 后 根据 
药品 名 称 和 数量 计算 总 价 ， 药 房 工 作 人 员 根 据 药品 名 称 和 数量 准备 药品 ， 如 图 26-1 所 示 : 


人 民 医 院 
处 方 移 
医疗 证 / 医保 卡号 
性 别 , 男 年 玖 : 25 
门诊 / 住院 遍历 号 ，475358 科室 ， 荔 房 
诊断 ， 陆涛 开具 日 期 ，2010 年 09 月 10 日 
电话 地 址 ,广州 大 通 直 加 129 导 305 


Rp 
收费 名 称 规格 单位 数 重 用 法 
1 背 贫 迷 Wu 颖 2 biry th 








2 ”黄连 系 针 Sorl 变 2 biry 小 


3 ”得 芍 楼 其 水 250n] 硕 1 WI? 





2 
药房 工作 人 员 


词 配 药师 ， 核对 、 发 药 药 师 ， 
鸭 懂 员 ， 





图 26-1 医院 处 方 单 处 理 示 意图 。 


在 图 26-1 中 ， 我 们 可 以 将 处 方 单 看 成 一 个 药品 信息 的 集合 ， 里 面包 含 了 一 种 或 多 种 不 同类 型 的 
药品 信息 ， 不 同类 型 的 工作 人 员 (如 划 价 人 员 和 药房 工作 人 员 ) 在 操作 同一 个 药品 信息 集合 
时 将 提供 不 同 的 处 理 方式 ， 而 且 可 能 还 会 增加 新 类 型 的 工作 人 员 来 操作 处 方 单 。 

在 软件 开发 中 ， 有 时 候 我 们 也 需要 处 理 像 处 方 单 这 样 的 集合 对 象 结构 ， 在 该 对 象 结构 中 存储 
了 多 个 不 同类 型 的 对 象 信息 ， 而 且 对 同一 对 象 结构 中 的 元 素 的 操作 方式 并 不 唯一 ， 可 能 需要 
提供 多 种 不 同 的 处 理 方式 ， 还 有 可 能 增加 新 的 处 理 方 式 。 在 设计 模式 中 ， 有 一 种 模式 可 以 满 
足 上 述 要 求 ， 其 模式 动机 就 是 以 不 同 的 方式 操作 复杂 对 象 结 构 ， 该 模式 就 是 我 们 本 章 将 要 介 
绍 的 访问 者 模式 。 

26.1 OA 系统 中 员工 数据 汇总 

Sunny 软 件 公 司 欲 为 某 银 行 开 发 一 套 OA 系 统 ， 在 该 OA 系统 中 包含 一 个 员工 信息 管理 子 系统 ， 
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该 银行 员工 包括 正式 员工 和 临时 工 ， 每 同人 力 资源 部 和 财务 部 等 部 2 
总 ， 汇 总 数据 包括 员工 工作 时 间 、 员 工 工资 等 。 该 公司 基本 制度 如 


(1) 正式 员工 (Full time Employee) 每 周 工作 时 间 为 40 小 时 ， 不 同 级 别 、 不 同 部 门 的 员工 每 周 基 
本 工资 不 同 ; 如 果 超 过 40 小 时 ， ee es 所 缺 
时 间 按 照 请 假 处 理 ， 请 假 所 扣 工 资 以 80 元 /小 时 计算 ， 直 到 基本 工资 扣除 到 零 为 止 。 除 了 记录 
和 


(2) 临时 工 (Part time Employee) 每 周 工作 时 间 不 国定 ， 基 本 工资 按 小 时 计算 ， 不 同 岗位 的 临时 
工 小 时 工资 不 同 。 人 力 资源 部 只 需 记 录 实 际 工作 时 间 。 


人 力 资源 部 和 财务 部 工作 人 员 可 以 根据 各 自 的 需要 对 员工 数据 进行 汇总 处 理 ， 人 力 资 源 部 负 
责 汇总 每 周 员工 工作 时 间 ， 而 财务 部 负责 计算 每 周 员工 工资 。 


Sunny 软 件 公司 开发 人 员 针 对 上 述 需 求 ， 提 出 了 一 个 初始 解决 方案 ， 其 核心 代码 如 下 所 示 : 
import java.util.*,; 


class EmployeeList 


{ 


private ArrayList<Employee> list = new ArrayList<Employee>(); // 


// 增 加 员工 
public void addEmployee(Employee employee) 
{ 


} 


// 处 理 员工 数据 
public void handle(String departmentName) 
{ 


list.add(employee); 


if(departmentName.equalsIgnoreCase(" 财 务 部 ")) // 财 务 部 处 理 员 工 数 
for(Object obj : list) 
if(obj.getClass().getName().equalsIgnoreCase("Fulltil 
System.out.println(" 财 务 部 处 理 全 职员 工 数据 ! ")， 
} 
else 


{ 
} 


System.out.println(" 财 务 部 处 理 兼 职员 工 数据 ! ")， 
} 
} 要 本 | 
else if(departmentName .equalsIgnoreCcase(" 人 力 资 源 部 " ) ) // 人 力 资 
for(Object obj : list) 
if(obj.getClass().getName().equalsIgnoreCase("Fulltil 
System.out.println(" 人 力 资源 部 处 理 全 职员 工 数 据 ! ")，; 


} 


else 
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System.out.println(" 人 力 资 源 部 处 理 兼 职员 工 数据 |! " )， 


} 


在 EmployeeList 类 的 handle() 方 法 中 ， 通 过 对 部 门 名 称 和 员工 类 型 进行 判断 ， 不 同 部 门 对 不 同类 
型 的 员工 进行 了 不 同 的 处 理 ， 满 足 了 员工 数据 汇总 的 要 求 。 但 是 该 解决 方案 存在 如 下 几 个 问 
题 : 


(1) EmployeeList 类 非常 庞大 ， 它 将 各 个 部 门 处 理 各 类 员工 数据 的 代码 集中 在 一 个 类 中 ， 在 有 具 
体 实 现时 ， 代 码 将 相当 宛 长 ，EmployeeList 类 承担 了 过 多 的 职责 ， 既 不 方便 代码 的 复 用 ， 也 不 
利于 系统 的 扩展 ， 违 背 了 “单一 职责 原则 ”。 


(2) 在 代码 中 包含 大 量 的 rif. .else.…" 条 件 判 断 语句 ， 既 需要 对 不 同 部 门 进行 判断 ， 又 需要 对 不 
同 美 型 的 员工 进行 判断 ， 还 将 出 现 嵌 套 的 条 件 判断 语 旬 ， 导 致 测试 和 维护 难度 增 大 。 


(3) 如 果 要 增加 一 个 新 的 部 门 来 操作 员工 集合 ， 不 得 不 修改 EmployeeList 类 的 源 代 码 ， 在 
handle() 方 法 中 增加 一 个 新 的 条 件 判 断 语 句 和 一 些 业务 处 理 代 码 来 实现 新 部 门 的 访问 操作 。 这 
违背 了 “ 开 闭 原则 ”， 系统 的 灵活 性 和 可 扩展 性 有 待 提高 。 


(4) 如 果 要 增加 一 种 新 类 型 的 员工 ， 同 样 需要 修改 EmployeeList 类 的 源 代码 ， 在 不 同 部 门 的 处 理 
代码 中 增加 对 新 类 型 员工 的 处 理 逻 辑 ， 这 也 违背 了 “ 开 闭 原则 ”。 如 何 解 决 上 述 问题 ?了 如 何 为 
同一 集合 对 象 中 的 元 素 提 供 多 种 不 同 的 操作 方式 ? 访问 者 模式 就 是 一 个 值得 考虑 的 解决 方 

案 ， 它 可 以 在 一 定 程度 上 解决 上 述 问题 (解决 大 部 分 问题 ) 。 访 问 者 模式 可 以 为 为 不 同类 型 
的 元 素 提 供 多 种 访问 操作 方式 ， 而 且 可 以 在 不 修改 原 有 系统 的 情况 下 增加 新 的 操作 方式 。 
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26.2 访问 者 模式 概述 

访问 者 模式 是 一 种 较为 复杂 的 行为 型 设计 模式 ， 它 包含 访问 者 和 被 访问 元 素 两 个 主要 组 成 部 
分 ， 这 些 被 访问 的 元 素 通常 具有 不 同 的 类 型 ， 且 不 同 的 访问 者 可 以 对 它们 进行 不 同 的 访问 操 
作 。 例 如 处 方 单 中 的 各 种 药品 信息 就 是 被 访问 的 元 素 ， 而 划 价 人 员 和 药房 工作 人 员 就 是 访问 
者 。 访 问 者 模式 使 得 用 户 可 以 在 不 修改 现 有 系统 的 情况 下 扩展 系统 的 功能 ， 为 这 些 不 同类 型 
的 元 素 增 加 新 的 操作 。 


在 使 用 访问 者 模式 时 ， 被 访问 元 素 通常 不 是 单独 存在 的 ， 它 们 存储 在 一 个 集合 中 ， 这 个 集合 
被 称 为 "对象 结 构 >”， 访 问 者 通过 遍历 对 象 结构 实现 对 其 中 存储 的 元 素 的 逐个 操作 。 


访问 者 模式 定义 如 下 : 

访问 者 模式 (Visitor Pattern): 提 供 一 个 作用 于 某 对 象 结构 中 的 各 元 素 的 操作 表示 ， 它 使 我 们 可 以 
在 不 改变 各 元 素 的 类 的 前 提 下 定义 作用 于 这 些 元 素 的 新 操作 。 访 问 者 模式 是 一 种 对 象 行为 型 
模式 。 

访问 者 模式 的 结构 较为 复杂 ， 其 结构 如 图 26-2 所 示 : 
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+ visitConcreteElementA ( 
ConcreteElementA elementA) 
+ VisitConcreteElementB ( 
ConcreteElementB elementB) 
A 


= 
+ visitConcreteElementA ( + visitConcreteElementA ( 
ConcreteElementA elementA) ConcreteElementA elementA) 
+ VisitConcreteElementB ( + VisitConcreteElementB ( 
ConcreteElementB elementB) ConcreteElementB elementB) 


ConcreteElementA ConcreteElemeniB 
[CSS ES 
+ accept (Visitor visitor) + accept (Visitor visitor) 





的 


到 的 
了 ’ 


visitor.visitConcreteElementA(this); visitor.visitConcreteElementB(this); 
4 


26-2 访问 者 模式 结构 图 。 
在 访问 者 模式 结构 图 中 包含 如 下 几 个 角色 : 
eVistor (抽象 访问 者 ) : 抽象 访问 者 为 对 象 结构 中 每 一 个 具体 元 素 类 ConcreteElement 声 明 一 


个 访问 操作 ， 从 这 个 操作 的 名 称 或 参数 类 型 可 以 清楚 知道 需要 访问 的 具体 元 素 的 类 型 ， 具 体 
访问 者 需要 实现 这 些 操作 方法 ， 定 义 对 这 些 元 素 的 访问 操作 。 


“|+ operationA () .|+ operationB () 


eConcreteVisitor ( 具体 访问 者 ) : 具体 访问 者 实现 了 每 个 由 抽象 访问 者 声明 的 操作 ， 每 一 个 操 
作用 于 访问 对 象 结构 中 一 种 类 型 的 元 素 。 


eElement (抽象 元 素 ) : 抽象 元 素 一 般 是 抽象 类 或 者 接口 ， 它 定义 一 个 accept() 方 法 ， 该 方法 
通常 以 一 个 抽象 访问 者 作为 参数 。【 稍 后 将 介绍 为 什么 要 这 样 设计 。】 


eConcreteElement (具体 元 素 ) : 具体 元 素 实 现 了 accept() 方 法 ， 在 accept() 方 法 中 调用 访问 者 
的 访问 方法 以 便 完成 对 一 个 元 素 的 操作 。 


e@ ObjectStructure (对 象 结构 ) : 对 象 结构 是 一 个 元 素 的 集合 ， 它 用 于 存放 元 素 对 象 ， 并 且 提 
供 了 遍历 其 内 部 元 素 的 方法 。 它 可 以 结合 组 合 模式 来 实现 ， 也 可 以 是 一 个 简单 的 集合 对 象 ， 
如 一 个 List 对 象 或 一 个 Set 对 象 。 


访问 者 模式 中 对 象 结构 存储 了 不 同类 型 的 元 素 对 象 ， 以 供 不 同 访问 者 访问 。 访 问 者 模式 包括 
两 个 层次 结构 ， 一 个 是 访问 者 层次 结构 ， 提 供 了 抽象 访问 者 和 具体 访问 者 ， 一 个 是 元 素 层 次 
结构 ， 提 供 了 抽象 元 素 和 具体 元 素 。 相 同 的 访问 者 可 以 以 不 同 的 方式 访问 不 同 的 元 素 ， 相 同 
的 元 素 可 以 接受 不 同 访问 者 以 不 同 访 问 方式 访问 。 在 访问 者 模式 中 ， 增 加 新 的 访问 者 无 须 修 
改 原 有 系统 ， 系 统 具 有 较 好 的 可 扩展 性 。 
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在 访问 者 模式 中 ， 抽 象 访问 者 定义 了 访问 元 素 对 象 的 方法 ， 通 常 为 每 一 种 类 型 的 元 素 对 象 都 
提供 一 个 访问 方法 ， 而 具体 访问 者 可 以 实现 这 些 访问 方法 。 这 些 访问 方法 的 命名 一 般 有 两 种 
方式 : 一 种 是 直接 在 方法 名 中 标明 待 访问 元 素 对 象 的 具体 类 型 ， 如 visitElementA(ElementA 
elementA)， 还 有 一 种 是 统一 取 名 为 visit()， 通 过 参数 类 型 的 不 同 来 定义 一 系列 重 载 的 visit() 方 
法 。 当 然 ， 如 果 所 有 的 访问 者 对 某 一 类 型 的 元 素 的 访问 操作 都 相同 ， 则 可 以 将 操作 代码 移 到 
抽象 访问 者 类 中 ， 其 典型 代码 如 下 所 示 : 


abstract class Visitor 


{ 
public abstract void visit(ConcreteElementA elementA); 
public abstract void visit(ConcreteElementB elementB); 
public void visit(ConcreteElementC elementcC ) 
// 元 素 ConcreteElementC 操 作 代 码 
} 
} 


在 这 里 使 用 了 重 载 visit() 方 法 的 方式 来 定义 多 个 方法 用 于 操作 不 同类 型 的 元 素 对 象 。 在 抽象 访 
问 者 Visitor 类 的 子 类 ConcreteVisitor 中 实现 了 抽象 的 访问 方法 ， 用 于 定义 对 不 同类 型 元 素 对 象 
的 操作 ， 具 体 访 问 者 类 典型 代码 如 下 所 示 : 


class ConcreteVisitor extends Visitor 


{ 
public void visit(ConcreteElementA elementA) 
// 元 素 ConcreteElementA 操 作 代 码 
public void visit(ConcreteElementB elementB) 
// 元 素 ConcreteElementB 操 作 代 码 
} 
} 


对 于 元 素 类 而 言 ， 在 其 中 一 般 都 定义 了 一 个 accept0 〇 方法， 用 于 接受 访问 者 的 访问 ， 典 型 的 抽 
象 元 素 类 代码 如 下 所 示 : 


interface Element 


‘ 
} 


需要 注意 的 是 该 方法 传 入 了 一 个 抽象 访问 者 Visitor 类 型 的 参数 ， 即 针对 抽象 访问 者 进行 编程 ， 
而 不 是 具体 访问 者 ， 在 程序 运行 时 再 确定 具体 访问 者 的 类 型 ， 并 调用 具体 访问 者 对 象 的 visitO 
方法 实现 对 元 素 对 象 的 操作 。 在 抽象 元 素 类 Element 的 子 类 中 实现 了 accept(0 方 法 ， 用 于 接受 访 
问 者 的 访问 ， 在 具体 元 素 类 中 还 可 以 定义 不 同类 型 的 元 素 所 特有 的 业务 方法 ， 其 典型 代码 如 
下 所 示 : 


public void accept(Visitor visitor); 


class ConcreteElementA implements Element 


{ 
public void accept(Visitor visitor) 
{ 
visitor.visit(this); 
} 
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public void operationA() 
// 业 务 方法 


} 


在 具体 元 素 类 ConcreteElementA 的 accept() 方 法 中 ， 通 过 调用 Visitor 类 的 visit() 方 法 实现 对 元 素 
的 访问 ， 并 以 当前 对 象 作为 visit() 方 法 的 参数 。 其 具体 执行 过 程 如 下 : 


(1) 调用 具体 元 素 类 的 accept(Visitor visitor) 方 法 ， 并 将 Visitor 子 类 对 象 作为 其 参数 ; 


(2) 在 具体 元 素 类 accept(Visitor visitor) 方 法 内 部 调用 传 入 的 Visitor 对 象 的 Vvisit() 方 法 ， 如 
Visit(ConcreteElementA elementA)， 将 当前 具体 元 素 类 对 象 (this) 作 为 参数 ， 如 visitor.visit(this) ; 


(3) 执行 Visitor 对 象 的 visit() 方 法 ， 在 其 中 还 可 以 调用 具体 元 素 对 象 的 业务 方法 。 

这 种 调用 机 制 也 称 为 “双重 分 派 ”， 正 因为 使 用 了 双重 分 派 机 制 ， 使 得 增加 新 的 访问 者 无 须 修改 
现 有 类 库 代 码 ， 只 需 将 新 的 访问 者 对 象 作为 参数 传 入 具体 元 素 对 象 的 accept() 方 法 ， 程 序 运行 
时 将 回调 在 新 增 Visitor 类 中 定义 的 visit() 方 法 ， 从 而 增加 新 的 元 素 访问 方式 。 

思考 

双重 分 派 机 制 如 何 用 代码 实现 ? 


在 访问 者 模式 中 ， 对 象 结构 是 一 个 集合 ， 它 用 于 存储 元 素 对 象 并 接受 访问 者 的 访问 ， 其 典型 
代码 如 下 所 示 : 


class 0bjectStructure 


private ArrayList<ELement> list = new ArrayList<Element>(); // 定 : 
public void accept(Visitor visitor) 
: Iterator i=list.iterator(); 
while(i.hasNext()) 
((Element)i.next()).accept(visitor); // 遍 历 访问 集合 中 的 每 一 
} 
public void addElement(Element element) 
list.add(element); 
} 
public void removeElement (Element element) 
list.remove(element); 
} 
} 


在 对 象 结构 中 可 以 使 用 和 迭代 器 对 存储 在 集合 中 的 元 素 对 象 进 行 遍历 ， 并 逐个 调用 每 一 个 对 象 
的 accept( 方 法 ， 实 现 对 元 素 对 象 的 访问 操作 。 


437 


操作 复杂 对 象 结 构 访问 者 模式 (二) 





思考 
访问 者 模式 是 否 符合 “ 开 闭 原则 ”? 【从 增加 新 的 访问 者 和 增加 新 的 元 素 两 方面 考虑 。]】 
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26.3 完整 解决 方案 


Sunny 软 件 公司 开发 人 员 使 用 访问 者 模式 对 OA 系统 中 员工 数据 汇总 模块 进行 重 构 ， 使 得 系统 
可 以 很 方便 地 增加 新 类 型 的 访问 者 ， 更 加 符合 “单一 职责 原则 ”和 “ 开 闭 原则 ”， 重 构 后 的 基本 结 


构 如 图 26-3 所 示 : 
{abstract} 
| 


+ visit (FulltimeEmployee employee) :void 
+ visit (ParttimeEnployee envployee) :void 
A A 
























| 
+ vist (FulltimeEmployee employee) :void 
+ visit (ParttimeEmployee employee) :void 


HRDepartment 
| aa 
+ visit (FulltimeEmployee employee) :void 
+ visit (PartimEmployee employee) :void 














- list : ArrayList = new ArrayList() 
+ addEmployee (Employee employee) :void 
+ accept (Department handler) :void 






必 Employee 
| 
+ accept (Department handler) :void 


Ee EN 













- name :String 

- hourWage : double 

- WorkTime :int 

+ ParttimeEmployee (String name, 
double hourWage, int workTime) 


FulltimeEmployee 
- name :String 
- weekyWage : double 
- workTime :int 
+ FullimeEmployee (String name, 
double weekyWage, int workTime) 
+ setName (String name) 





+ setName (String name) 

+ getName () 
+ setHourWage (double hourWage) : 
+ getHourlyWage () 
+ setVorkTime (int workTime) 

+ getWorkTime () 

+ accept{Department handler) 


+ getName () . 
+ setVWeekyWage (double weekHyWage) : 
+ getWeekHyVWage () id 
+ setWorkTime (int workT ime) 

+ getWorkTime () 

+ accept (Department handlen) 





26-3 员工 数据 汇总 模块 结构 图 。 


在 图 26-3 中 ，FADepartment 表 示 财 务 部 ，HRDepartment 表 示人 力 资源 部 ， 它 们 充当 具体 访问 者 
角色 ， 其 抽象 父 类 Department 充 当 抽 象 访问 者 角色 ; EmployeeList 充 当 对 象 结构 ， 用 于 存储 员 
工 列表 ; FulltimeEmployee 表 示 正 式 员工 ，ParttimeEmployee 表 示 临 时 工 ， 它 们 充当 具体 元 素 角 
色 ， 其 父 接 口 Employee 充 当 抽 象 元 素 角色 。 完 整 代码 如 下 所 示 : 


import java.util.*; 


// 员 工 类 : 抽象 元 素 类 
interface Employee 


{ 
public void accept(Department handler); // 接 受 一 个 抽象 访问 者 访问 
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} 


// 全 职员 工 类 : 具体 元 素 类 
class FulltimeEmployee implements Employee 


{ 
private String name; 
private double weeklywage; 
private int workTime; 
public FulltimeEmployee(String name,double weeklywage,int workTii 
{ 
this.name = name; 
this.weeklyWage = weeklywage; 
this.workTime = workTime; 
} 
public void setName(String name) 
{ 
this.name = name; 
} 
public void setweeklywage(double weeklywage) 
{ 
this.weeklyWage = weeklywage; 
} 
public void setworkTime(int workTime) 
{ 
this.workTime = workTime; 
} 
public String getName() 
{ 
return (this.name); 
} 
public double getweeklywage() 
{ 
return (this.weeklywage); 
} 
public int getworkTime() 
{ 
return (this.workTime); 
} 
public void accept(Department handler) 
{ 
handler .visit(this); // 调 用 访问 者 的 访问 方法 
} 
} 


// 兼 职员 工 类 : 具体 元 素 类 
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class ParttimeEmployee implements Employee 


{ 
private String name; 
private double hourwage; 
private int workTime; 
public ParttimeEmployee(String name,double hourWage,int workTime 
{ 
this.name = name; 
this.hourwage = hourWage; 
this.workTime = workTime 
} 
public void setName(String name) 
{ 
this.name = name; 
} 
public void setHourwWage(double hourwage) 
{ 
this.hourwage = hourWage; 
} 
public void setworkTime(int workTime) 
{ 
this.workTime = workTime; 
} 
public String getName() 
{ 
return (this.name); 
} 
public double getHourwage() 
{ 
return (this.hourwage); 
} 
public int getworkTime() 
{ 
return (this.workTime); 
} 
public void accept(Department handler) 
{ 
handler .visit(this); // 调 用 访问 者 的 访问 方法 
} 
} 


// 部 门类 : 抽象 访问 者 类 
abstract class Department 


// 声 明 一 组 重 载 的 访问 方法 ， 用 于 访问 不 同类 型 的 具体 元 素 
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public abstract void visit(FulltimeEmployee employee); 
public abstract void visit(ParttimeEmployee employee); 


} 


// 财 务 部 类 : 具体 访问 者 类 
class FADepartment extends Department 


// 实 现 财务 部 对 全 职员 工 的 访问 
public void visit(FulltimeEmployee employee) 


{ 
int workTime = employee.getWworkTime(); 
double weekwage = employee.getweeklywage(); 
if(workTime > 40) 
{ 
weekwage = weekWage + (workTime - 40) * 100; 
else if(workTime < 40) 
{ 
weekwage = weekWage - (40 - workTime) * 80; 
If(weekwage < 0) 
{ 
weekwage = 0; 
} 
. 
System.out .printlLn(" 正 式 员工 " + employee.getName() + "实际 工资 
} 


// 实 现 财务 部 对 兼职 员工 的 访问 
public void visit(ParttimeEmployee employee) 


{ 
int workTime = employee.getWorkTime(); 
double hourwage = employee.getHourwage(); 
System.out.println(" 临 时 工 " + employee.getName() + "实际 工资 为 : 
} 


} 


// 人 力 资源 部 类 : 具体 访问 者 类 
class HRDepartment extends Department 


// 实 现 人 力 资 源 部 对 全 职员 工 的 访问 
public void visit(FulltimeEmployee employee) 


{ 
int workTime = employee.getWworkTime(); 
System.out.println(" 正 式 员 工 " + employee.getName() + "实际 工作 
if(workTime > 40) 
{ 
System.out.println(" 正 式 员工 " + employee.getName() + "加 班 | 
else if(workTime < 40) 
{ 
System.out.println(" 正 式 员工 " + employee.getName() + "请 假 | 
} 
} 
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// 实 现 人 力 资源 部 对 兼职 员工 的 访问 
public void visit(ParttimeEmployee employee) 


{ 


int workTime = employee.getworkTime(); 
System.out.println(" 临 时 工 " + employee.getName() + "实际 工作 时 让 


} 


// 员 工 列表 类 : 对 象 结构 
class EmployeeList 


{ 
// 定 义 一 个 集合 用 于 存储 员工 对 象 
private ArrayList<Employee> list = new ArrayList<Employee>(); 


public void addEmployee(Employee employee) 
{ 


} 


// 人 遍历 访问 员工 集合 中 的 每 一 个 员工 对 象 
public void accept(Department handler) 


{ 


list.add(employee); 


for(Object obj : list) 


((Employee)obj).accept(handler); 


} 


为 了 提高 系统 的 灵活 性 和 可 扩展 性 ， 我 们 将 具体 访问 者 类 的 类 名 存储 在 配置 文件 中 ， 并 通过 
工具 类 XMLUtil 来 读 取 配 置 文件 并 反射 生成 对 象 ，XMLUtil 类 的 代码 如 下 所 示 : 


Import javax.xml.parsers.*,; 
import org.w3c.dom,*， 

Import org.xml.sax.SAXException; 
import java.io.*,; 

class XMLUtil1 


// 该 方法 用 于 从 XML 配置 文件 中 提取 具体 类 类 名 ， 并 返回 一 个 实例 对 象 
public static Object getBean() 
{ 
try 
{ 
// 创 建文 档 对 象 
DocumentBuilderFactory dFactory = DocumentBuilderFactory 
DocumentBuilder builder = dFactory,newDocumentBuilder( ); 
Document doc 
doc = builder.parse(new File("config.xml")); 


// 获 取 和 包含 类 名 的 文本 节点 
NodeList nl = doc.getElementsByTagName("className"); 
Node classNode=nl1.item(0).getFirstChild(); 
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String cName=classNode.getNodeVvalue(); 


// 通 过 类 名 生成 实例 对 象 并 将 其 返回 
Class c=Class.forName(cName); 
Object obj=c.newInstance( ); 
return obj; 


h(Exception e) 


e.printStackTrace( ); 
return null; 


配置 文件 config.xml 中 存储 了 具体 访问 者 类 的 类 名 ， 代 码 如 下 所 示 : 


} 
catc 
{ 
} 
} 
} 
<?xml1 versio 
<config> 
<classNa 
</config> 


Ne 0"?> 


me>FADepartment</className> 


编写 如 下 客户 端 测试 代码 : 


class Client 


{ 
public s 


{ 
Empl 
Empl 


fte1 
fte2 
fte3 
ptel1 
pte2 


JISt ， 
JILSt ， 
JILSt ， 
JILSt ， 
JISt ， 


Depa 

dep 

J]ist 
} 
编译 并 运行 程序 


正式 员工 张无忌 


tatic void main(String args[]) 


OyeeList list = new EmployeeList(); 
oyee ftel,fte2,fte3,ptel,pte2; 


new FulltimeEmployee(" 张 无 态 ", 3200.00,45); 
new FulltimeEmployee(" 杨 过 ",2000.009, 40); 
new FulltimeEmployee(" 段 誉 ",2400 .909,38); 
new ParttimeEmployee(" 洪 七 公 ",80.00,20); 
new ParttimeEmp1loyee(" 郭 靖 " ,60.00,18)， 


addEmployee(fte1); 
addEmployee (fte2); 
addEmployee (fte3); 
addEmployee(pte1); 
addEmployee(pte2); 


rtment dep; 


= (Department )XMLUtil.getBean( ); 
.accept (dep); 


， 输出 结果 如 下 : 


实际 工资 为 : 3700.0 元 。 


正式 员工 杨过 实际 工资 为 : 2000.0 元 。 
正式 员工 段 誉 实际 工资 为 : 2240 ,0 元 。 
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临时 工 洪 七 公 实 际 工资 为 : 1600.0 元 。 
临时 工 郭 靖 实际 工资 为 : 1080 .9 元 。 


如 果 需 要 更 换 具 体 访 问 者 类 ， 无 须 修 改 源 代 码 ， 只 需 修 改 配置 文件 ， 例 如 将 访问 者 类 由 财务 
部 改 为 人 力 资 源 部 ， 只 需 将 存储 在 配置 文件 中 的 具体 访问 者 类 FADepartment 改 为 
HRDepartment， 如 下 代码 所 示 : 


<?xml1 version="1.0"?> 

<config> 
<className>HRDepartment</className> 

</config> 


重新 运行 客户 端 程序 ， 输 出 结果 如 下 : 


正式 员工 张无忌 实际 工作 时 间 为 : 45 小 时 。 
正式 员工 张 无 总 加 班 时 间 为 : 5 小 时 。 

正式 员工 杨过 实际 工作 时 间 为 : 40 小 时 。 
正式 员工 段 誉 实际 工作 时 间 为 : 38 小 时 。 
正式 员工 段 誉 请 假 时 间 为 : 2 小 时 。 

临时 工 洪 七 公 实际 工作 时 间 为 : 20 小 时 。 
临时 工 郭 靖 实际 工作 时 间 为 : 18 小 时 。 


如 果 要 在 系统 中 增加 一 种 新 的 访问 者 ， 无 须 修改 源 代 码 ， 只 要 增加 一 个 新 的 具体 访问 者 类 即 
可 ， 在 该 具体 访问 者 中 封装 了 新 的 操作 元 素 对 象 的 方法 。 从 增加 新 的 访问 者 的 角度 来 看 ， 访 
问 者 模式 符合 “ 开 闭 原则 ”。 


如 果 要 在 系统 中 增加 一 种 新 的 具体 元 素 ， 例 如 增加 一 种 新 的 员工 类 型 为 “退休 人 员 ”， 由 于 原 有 
系统 并 未 提供 相应 的 访问 接口 (在 抽象 访问 者 中 没有 声明 任何 访问 “退休 人 员 ” 的 方法 ) ， 因 此 
必须 对 原 有 系统 进行 修改 ， 在 原 有 的 抽象 访问 者 类 和 具体 访问 者 类 中 增加 相应 的 访问 方法 。 
从 增加 新 的 元 素 的 角度 来 看 ， 访 问 者 模式 违背 了 “ 开 闭 原则 ”。 


综 上 所 述 ， 访 问 者 模式 与 抽象 工厂 模式 类 似 ， 对 “ 开 闭 原则 ”的 支持 具有 倾斜 性 ， 可 以 很 方便 地 
添加 新 的 访问 者 ， 但 是 添加 新 的 元 素 较 为 麻烦 。 
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访问 者 模式 (四 ) 
访问 者 模式 (四 ) 


操作 复杂 对 象 结构 
操作 复杂 对 角 结 构 


26.4 访问 者 模式 与 组 合 模式 联 用 


在 访问 者 模式 中 ， 包 含 一 个 用 于 存储 元 素 对 象 集合 的 对 象 结构 ， 我 们 通常 可 以 使 用 迭代 器 来 
遍历 对 象 结 构 ， 同 时 具体 元 素 之 间 可 以 存在 整体 与 部 分 关系 ， 有 些 元 素 作 为 容器 对 象 ， 有 些 
元 素 作 为 成 员 对 象 ， 可 以 使 用 组 合 模式 来 组 织 元 素 。 引 入 组 合 模式 后 的 访问 者 模式 结构 图 如 


图 26-4 所 示 : 





5 







| Fk 
+ accept (抽象 访问 者 VvV) :void 


| 了 
+ accept (抽象 访问 者 V) :void 


children 


: 6 
| 
+ accept (抽象 访问 者 V) :void 





frelemert :elements) 





elemert.accept(v). 





for(child :children) 






child.accept(v); 


图 26-4 访问 者 模式 与 组 合 模 式 联 用 示意 图 + 
需要 注意 的 是 ， 在 图 26-4 所 示 结 构 中 ， 由 于 叶子 元 素 的 遍历 操作 已 经 在 容器 元 素 中 完成 ， 因 此 
要 防止 单独 将 已 增加 到 容器 元 素 中 的 叶子 元 素 再 次 加 入 对 象 结 构 中 ， 对 象 结 构 中 只 保存 容器 
元 素 和 孤立 的 叶子 元 素 。 
26.5 访问 者 模式 总 结 
由 于 访问 者 模式 的 使 用 条 件 较 为 苛刻 ， 本 身 结构 也 较为 复杂 ， 因 此 在 实际 应 用 中 使 用 频率 不 
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是 特别 高 。 当 系统 中 存在 一 个 较为 复杂 的 对 象 结 构 ， 且 不 同 访问 者 对 其 所 采取 的 操作 也 不 相 
同时 ， 可 以 考虑 使 用 访问 者 模式 进行 设计 。 在 XML 文档 解析 、 编 译 器 的 设计 、 复 杂 集 合 对 象 
的 处 理 等 领域 访问 者 模式 得 到 了 一 定 的 应 用 。 

1. 主 要 优点 

访问 者 模式 的 主要 优点 如 下 : 


(1) 增加 新 的 访问 操作 很 方便 。 使 用 访问 者 模式 ， 增 加 新 的 访问 操作 就 意味 着 增加 一 个 新 的 具 
体 访问 者 类 ， 实 现 简单 ， 无 须 修改 源 人 代码， 符合“ 开 闭 原则 ”。 


(2) 将 有 关 元 素 对 象 的 访问 行为 集中 到 一 个 访问 者 对 象 中 ， 而 不 是 分 散在 一 个 个 的 元 素 类 中 。 
类 的 职责 更 加 清晰 ， 有 利于 对 象 结构 中 元 素 对 象 的 复 用 ， 相 同 的 对 象 结构 可 以 供 多 个 不 同 的 
访问 者 访问 。 

(3) 让 用 户 能 够 在 不 修改 现 有 元 素 类 层次 结构 的 情况 下 ， 定 义 作 用 于 该 层次 结构 的 操作 。 
2. 主 要 缺点 

访问 者 模式 的 主要 缺点 如 下 : 

(1) 增加 新 的 元 素 类 很 困难 。 在 访问 者 模式 中 ， 每 增加 一 个 新 的 元 素 类 都 意味 着 要 在 抽象 访问 
者 角色 中 增加 一 个 新 的 抽象 操作 ， 并 在 每 一 个 具体 访问 者 类 中 增加 相应 的 具体 操作 ， 这 违背 
了 “ 开 闭 原则 ”的 要 求 。 


(2) 破坏 封装 。 访 问 者 模式 要 求 访问 者 对 象 访问 并 调用 每 一 个 元 素 对 象 的 操作 ， 这 意味 着 元 素 
对 象 有 时 候 必 须 暴露 一 些 自己 的 内 部 操作 和 内 部 状态 ， 否 则 无 法 供 访 问 者 访问 。 


3. 适 用 场景 
在 以 下 情况 下 可 以 考虑 使 用 访问 者 模式 : 


(1) 一 个 对 象 结构 包含 多 个 类 型 的 对 象 ， 希 望 对 这 些 对 象 实施 一 些 依赖 其 具体 类 型 的 操作 。 在 
访问 者 中 针对 每 一 种 具体 的 类 型 都 提供 了 一 个 访问 操作 ， 不 同类 型 的 对 象 可 以 有 不 同 的 访问 
操作 。 


(2) 需要 对 一 个 对 象 结构 中 的 对 象 进行 很 多 不 同 的 并 且 不 相关 的 操作 ， 而 需要 避免 让 这 些 操 

作 “ 污 染 ” 这 些 对 象 的 类 ， 也 不 希望 在 增加 新 操作 时 修改 这 些 类 。 访 问 者 模式 使 得 我 们 可 以 将 相 
关 的 访问 操作 集中 起 来 定义 在 访问 者 类 中 ， 对 象 结构 可 以 被 多 个 不 同 的 访问 者 类 所 使 用 ， 将 
对 象 本 身 与 对 象 的 访问 操作 分 离 。 


(3) 对 象 结 构 中 对 象 对 应 的 类 很 少 改 变 ， 但 经 常 需要 在 此 对 象 结构 上 定义 新 的 操作 。 
练习 
Sunny 软 件 公司 欲 为 某 高 校 开 发 一 套 奖 励 审 批 系统 ， 该 系统 可 以 实现 教师 奖励 和 学 生 奖 励 
的 审批 (Award Check)， 如 果 教 师 发 表 论 文 数 超过 10 篇 或 者 学 生 论文 超过 2 篇 可 以 评选 科研 
奖 ， 如 果 教 师 教学 反馈 分 大 于 等 于 90 分 或 者 学 生平 均 成 绩 大 于 等 于 90 分 可 以 评选 成 绩优 


秀 奖 。 试 使 用 访问 者 模式 设计 该 系统 ， 以 判断 候选 人 集合 中 的 教师 或 学 生 是 否 符 合 某 种 
获奖 要 求 。 
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0 习 〈 复 
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设计 模式 与 足球 (一 ) 


TR 
设计 粹 式 刁 叉 于 (5) 


今天 晚上 2012 年 欧洲 杯 决 赛 (西班牙 VS 意大利 ) ， 作 为 一 名 铁杆 球迷 ， 偶 当然 不 会 错过 (请 
不 要 让 我 来 预测 比分 ， 我 不 是 章鱼 ， 更 何况 这 两 个 队 我 都 非常 喜欢 ， 输 赢 我 都 很 淡定 ， 微 
笑 ) ， 在 静 候 决 赛 的 这 段 时 间 ， 突 然 靖 发 一 个 想法 ， 将 设计 模式 跟 足 球 联系 到 一 起 写 点 哈 ， 
就 像 当 年 那 篇 知名 度 极 高 的 《 追 MM 与 设计 模式 》 一 样 ， 以 供 娱 乐 ! 吐 舌 头 ， 话 不 多 说 ， 即 刻 
动手 | 


创建 型 模式 


(1) 工厂 方法 模式 : 近年 来 大 型 足球 比赛 (世界杯 和 欧洲 杯 ) 的 指定 用 球 都 是 阿迪 达 斯 的 ( 据 
说 是 签 了 合同 的 ) ， 当 然 Adidas 足 球 是 由 Adidas 公 司 生 产 的 ， 除 此 之 外 ，Nike 公 司 也 生产 Nike 
足球 ，KAPPA (背靠背 ) 公司 也 生产 背靠背 足球 ， 足 球 生 产 商 是 工厂 ， 足 球 是 产品 。 增 加 一 
种 新 的 足球 品牌 ， 对 应 需要 增加 一 个 新 的 生产 商 。 


工厂 方法 模式 (Factory Method) : 定义 一 个 用 于 创建 对 象 的 接口 ， 让 子 类 决定 将 哪 一 个 类 实例 
化 。 工 厂 方法 模式 使 一 个 类 的 实例 化 延迟 到 其 子 类 。 


(2) 抽象 工厂 模式 : Adidas 工 厂 除了 生产 Adidas 足 球 外 ， 还 生产 Adidas 球 鞋 、 球 服 、 球 袜 
(adidas is all in) ; Nike 工 厂 也 生产 Nike 足 球 、 球 鞋 、 球 服 、 球 袜 等 ， 在 此 ，Adidas 和 Nike 是 
工厂 ， 同 一 品牌 的 足球 、 球 鞋 、 球 服 、 球 袜 构 成 了 一 个 产品 族 ， 一 个 工厂 可 以 生产 一 族 产 

品 ， 而 不 只 是 一 种 产品 。 


抽象 工厂 模式 (Abstract Factory): 提供 一 个 创建 一 系列 相关 或 相互 依赖 对 象 的 接口 ， 而 无 须 指定 
它们 具体 的 类 。 


(3) 单 例 模式 : 在 比赛 过 程 中 《在 场 上 的 ， 和 替补 不 莫 ) 每 个 球 队 的 守门 员 有 且 仅 有 一 个 ， 肯 定 
不 会 有 两 个 穿 相 同 球衣 的 守门 员 同 时 上 场 ， 这 不 是 单 例 吗 ? 如 果 布 冯 或 者 卡 西 能 出 场 ， 还 有 

哪个 意大利 或 者 西班牙 守门 员 敢 去 跟 他 们 抢 首发 呢 ? ? 布 冯 你 是 唯一 的 ! 卡 西 ， 你 也 是 ! 当 

然 ， 皮 尔 洛 也 是 ， 哈 维 也 是 ， 小 法 也 是 ， 巴 神 也 是 ..….. 原 来 有 这 人 么 多 单 例 。 


单 例 模式 (Singleton): 保证 一 个 类 仅 有 一 个 实例 ， 并 提供 一 个 访问 它 的 全 局 访问 点 。 


(4) 建造 者 模式 : 如 果 我 要 一 套 完整 的 意大利 国家 队 足 球 装备 ( 除 球 鞋 ， 这 个 貌似 没有 统 

一 ) : 包括 球衣 、 球 实 、 球 袜 ， 只 需 跟 某 专卖 店 销售 人 员 说 一 下 (想象 ， 想象 ..…..) : 我 要 一 
套 意 大 利 队 的 足球 装备 ， 大 小 为 XL， 返 回 给 你 的 是 一 套 经 典 的 蓝 色 意大利 国家 队 队 服 ， 包 括 
蓝 色 的 足球 袜 ; 当然 你 的 朋友 可 以 说 他 要 一 套 西 班 牙 队 的 足球 装备 ， 返 回 给 他 的 是 一 套红 色 
的 斗牛 士 足 球 装备 ， 袜 子 ， 当 然 也 是 红 的 。 在 此 ， 销 售 人 员 相 当 于 建造 者 模式 中 的 指挥 者 
(Director)， 他 向 用 户 返 回 一 个 复杂 产品 (足球 装备 )， 该 复杂 产品 由 多 个 部 件 组 成 (球衣 、 球 

裤 、 球 袜 等 )， 用 户 无 须 关 心 具 体 组 装 过 程 即 可 得 到 一 个 完整 的 复杂 产品 。 


建造 者 模式 (Builder): 将 一 个 复杂 对 象 的 构建 与 它 的 表示 分 离 ， 使 得 同样 的 构建 过 程 可 以 创建 
不 同 的 表示 。 


(5) 原型 模式 : 无 论 是 足球 还 是 球 服 ， 都 是 批量 生产 的 ， 例 如 2012 年 欧洲 杯 的 指定 用 球 Adidas 
探 区 12 (Tango 12) ， 先 做 一 个 原型 (模板) ， 然 后 照 着 生产 就 好 了 ， 想 要 多 少 就 生产 多 少 。 


原型 模式 (Prototype): 用 原型 实例 指定 创建 对 象 的 种 类 ， 并 且 通 过 拷贝 这 个 原型 来 创建 新 的 对 
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设计 模式 与 足球 (二) 


Tk 
a a 


结构 型 模式 


(6) 适配器 模式 : 很 多 足球 队 都 喜欢 请 外 国教 练 (其 中 有 一 支 我 们 都 非常 熟悉 的 国家 队 ， 名 字 
偶 就 不 说 了 ， 大 家 都 懂 的 ， 微 笑 ) ， 外 国教 练 请 回来 通常 很 难 跟 队员 直接 交流 (语言 不 

通 ) ， 因 此 需要 配 翻 译 ， 此 时 ， 翻 译 充当 了 教练 和 队员 之 间 的 适配器 ， 负 责 协 调教 练 和 队员 
之 间 的 交流 。 


例如 : pass --> shoot --> goal 转换 传 球 --> 射门 --> 进 球 


适配器 模式 (Adapter): 将 一 个 类 的 接口 转换 成 用 户 希 望 的 另 一 个 接口 ， 使 得 原本 由 于 接口 不 兼 
容 而 不 能 一 起 工作 的 那些 类 可 以 一 起 工作 。 


(7) 桥接 模式 : 在 足球 比赛 中 ， 有 人 踢 前 锋 、 有 人 踢 中 场 (前 腰 、 中 卫 ) 、 有 人 踢 后 卫 ; 当 
然 ， 有 人 习惯 踢 左 边 、 有 人 习惯 踢 右 边 、 也 有 人 喜欢 站 在 中 间 ， 因 此 诞生 了 左 中 卫 、 右 前 
锋 、 中 后 卫 、 右 后 卫 等 名 词 ， 难 道 这 不 是 两 个 变化 维度 的 组 合 吗 ? 


桥接 模式 (Bridge): 将 抽象 部 分 与 实现 部 分 分 离 ， 使 它们 都 可 以 独立 地 变化 。 


(8) 组 合 模式 : 2012 年 欧洲 杯 一 共 分 为 四 个 组 ， 每 个 组 四 个 队 ， 每 个 队 有 23 名 球员 ， 如 果 要 用 
一 个 图 来 表示 2012 年 欧洲 杯 全 体 球员 及 各 国 分 组 情况 ， 不 用 说 ， 一 定 是 个 树 状 图 ， 组 里 有 
队 ， 队 里 有 人 ， 如 果 想 要 召开 B 组 ( 赛 前 公认 的 死亡 之 组 ) 队员 大 会 ， 在 B 组 的 节点 上 写 下 通 
知 :“ 下 午 3 点 ， 召 开 重 要 会 议 ， 事 关 出 线 1”， 想 必 荷 兰 、 德 国 、 葡 萄 牙 、 和 丹麦 队员 都 会 积极 
响应 ， 随 叫 这 几 个 “ 苦 逼 > 队 位 于 同一 个 节点 的 分 支 上 呢 ? 微笑 


组 合 模式 (Composite): 将 对 象 组 合成 树 形 结构 以 表示 “部 分 -整体 ”的 层次 结构 ， 它 使 得 客户 对 单 
个 对 象 和 复合 对 象 的 使 用 具有 一 致 性 。 


(9) 装饰 模式 : 现在 足球 服 上 的 广告 越 来 越 多 了 ，2012 年 欧洲 杯 夺冠 热门 之 一 ( 赛 前 预测 ) 德 
国 队 队 服 胸 前 右边 一 个 奔驰 ， 左 边 一 个 阿迪 ， 当 然 还 可 以 继续 增加 ， 广 告 既 没 有 改变 球衣 的 
用 途 和 性 能 ， 还 能 起 到 装饰 效果 ， 增 加 收入 ， 何 乐 而 不 为 呢 ? 就 是 半 决 赛 没 能 够 让 巴 神 继 
续 “ 思 考 人 生 ”， 悲 催 的 德国 队 ! 增加 新 的 广告 ， 只 需 对 原 有 球 服 继续 装饰 即 可 。 


装饰 模式 (Decorator): 动态 地 给 一 个 对 象 添 加 一 些 额外 的 职责 ， 就 扩展 功能 而 言 ， 它 比 生成 子 
类 的 方式 更 为 灵活 。 


(10) 外 观 模 式 : 为 了 给 记者 和 球 队 (球员 、 教 练 等 ) 提供 一 个 交流 的 平台 ， 欧 洲 杯 组 委 会 在 每 
场 足 球 比 赛 前 后 都 安排 了 新 闻 发 布 会 ， 记 者 可 以 通过 新 闻 发 布 会 来 与 球 队 进行 沟通 交流 〈 虽 

然 不 是 每 个 队员 会 出 现在 新 闻 发 布 会 上 ) ， 在 此 ， 新 闻 发 布 会 充当 了 记者 (客户 端 ) 和 队 

员 、 教 练 ( 子 系统 ) 之 间 的 外 观 角色 。 当 然 ， 新 闻 发 布 会 并 不 会 影响 某 位 记者 单独 采访 某 位 
球员 (这 一 点 也 与 外 观 类 的 定义 一 致 ， 微 笑 ) 。 


外 观 模式 (Facade): 子 系 统 中 的 一 组 接口 提供 一 个 一 致 的 界面 ， 定 义 一 个 高 层 接口 ， 这 个 接口 
使 得 这 一 子 系统 更 加 容易 使 用 。 

(11) 享 元 模式 : 同一 个 国家 队 的 队员 ， 他 们 都 共享 着 一 个 伟大 的 称谓 ， 即 "XXX 国家 队 队 员 "， 
例如 “意大利 国家 队 队 员 ”、“ 西 班 牙 国家 队 队 员 ”( 一 说 到 “中 国 国家 队 队 员 * 就 伤心 ， 还 是 不 说 
了 ， 难 过 ) ， 因 此 ，"XXX 国 家 队 队 员 " 是 一 个 可 以 共享 的 内 部 状态 。 但 是 在 比赛 过 程 中 ， 每 
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个 队员 身 披 不 同 号 码 的 球衣 ， 球 衣 号 码 是 不 能 共享 的 ， 同 一 个 国家 队 的 队员 每 个 人 都 拥有 不 
同 的 号 码 ， 因 此 ， 球 衣 号 码 是 不 能 够 共享 的 外 部 状态 。 在 享 元 模式 中 区 分 了 对 象 的 内 部 状态 
和 外 部 状态 。 

享 元 模式 (Flyweight): 运用 共享 技术 有 效 地 支持 大 量 细 粒 度 的 对 象 。 

(12) 代理 模式 : 足球 场 外 ， 球 员 转 会 是 一 个 热门 话题 。 转 会 当然 离 不 开 球 员 的 经 纪 人 ， 经 纪 人 


将 球员 的 想法 传递 给 另 一 家 俱乐部 。 经 纪 人 就 是 球员 的 代理 ， 球 员 是 目标 对 象 ， 而 经 纪 人 是 
代理 对 象 ， 经 纪 人 隔离 了 球员 和 “客户 端 ?，“ 拍 广告 ， 请 找 我 的 经 纪 人 ”，“ 采 访 ， 请 找 我 的 经 


代理 模式 (Proxy) : 为 其 他 对 象 提供 一 个 代理 以 控制 对 这 个 对 象 的 访问 。 
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TR 
a a 


行为 型 模式 (上) 


(13) 职责 链 神 式 ; 布 冯 手 抛 球 给 基 耶 利 尼 、 基 耶 利 尼 传 给 皮尔 洛 、 皮 和 尔 洛 带 球 过 人 之 后 将 球 直 

给 快速 插 上 的 巴 洛 特 利 ， 巴 洛 特 利 倒 钧 射门 ， 球 进 了 ， 球 进 了 ， 又 是 巴 洛 特 利 ， 巴 洛 特 利 
i 
灵魂 附 体 ! 巴 洛 特 利 代 表 了 意大利 足球 悠久 的 历史 和 传统 ， 在 这 一 刻 他 不 是 一 个 人 在 战斗 ， 
他 不 是 一 个 人 ! 大 笑 


在 此 ， 足 球 就 是 一 个 请 求 ， 而 球员 就 是 请 求 的 处 理 者 ， 足 球 在 球员 间 不 断 进行 传递 ， 构 成 了 
一 条 传递 链 。 


职责 链 模 式 (Chain of Responsibility): 为 解除 请 求 的 发 送 者 和 接收 者 之 问 耦 合 ， 而 使 多 个 对 象 都 
有 机 会 处 理 这 个 请 求 ; 将 这 些 对 象 连 成 一 条 链 ， 并 沿 着 这 条 链 传递 该 请 求 ， 直 到 有 一 个 对 象 
处 理 它 。 


(14) 命令 模式 : 普兰 德 利 掌心 朝 外 ， 向 前 一 推 ， 意 大 利 全 线 压 上 ; 普兰 德 利 掌心 朝 内 ， 向 后 一 
拨 ， 意大利 全 线 退 防 ° 1 主教 练 ， 普兰 德 利 就 是 命令 的 发 送 者 ， 手势 就 是 命令 对 
象 ， 所 有 队员 都 是 命令 的 接收 者 。 不 同 的 命 令 对 象 将 对 应 不 同 的 执 和 有 于 动作 。 


命令 模式 (Command): 将 一 个 请 求 封装 为 一 个 对 象 ， 从 而 可 用 不 同 的 请 求 对 客户 进行 参数 化 ; 
对 请 求 排队 或 记录 请 求 日 志 ， 以 及 支持 可 取消 的 操作 。 


(15) 解释 器 s 模 式 : 在 足球 场 上 ， 教练 的 手势 就 是 一 门 语言 ， 有 的 表示 “ 传 球 ” 5 有 的 表示 “全 线 
压 上 ”， 有 的 表示 "全线 防守 >， 每 个 队员 都 需要 在 比赛 中 阅读 教练 的 手势 并 将 其 转换 成 执行 指 
令 ， 按 照 教练 的 意图 来 展开 攻守 。 


解释 器 模式 (Interpreter): 定义 语言 的 文法 ， 并 且 建 立 一 个 解释 器 来 解释 该 语言 中 的 句子 。 


(16) 迭代 器 模式 : 下 面 出 场 的 是 西班牙 队 : 1 号 守门 员 卡 西利 亚 斯 、3 号 后 卫 皮 克 、6 号 中 场 球 
员 伊 内 斯 塔 、8 号 哈 维 、9 号 托雷斯 ..…. 一 个 个 来 ， 不 急 ， 这 次 是 按照 球衣 号 码 ， 下 次 再 按照 位 
置 从 前 到 后 、 从 左 到 右 介 绍 一 次 。 西 班 牙 队 是 一 个 包含 多 个 队员 的 聚合 对 象 ， 可 以 提供 一 个 
迭代 器 来 遍历 其 中 的 队员 。 


和 迭代 器 模式 (Iterator): 提供 一 种 方法 顺序 访问 一 个 聚合 对 象 中 各 个 元 素 ， 而 又 不 需 暴 露 该 对 象 
的 内 部 表示 。 


(17) 中 介 者 模式 : 比赛 梯 倒 怎么 办 ? 看 裁判 ; 没 顶 到 球 怎么 办 了 看 裁判 ; 被 踢 中 要 定 部 位 怎么 
办 ?看 裁判 ; 球 到 底 进 没 进 ， 看 裁判 |。 裁判 经 常 是 足球 赛场 的 主角 ， 当 两 队 队 员 发 生 冲突 
时 ， 裁 判 还 是 很 重要 滴 ， 他 充当 了 球员 之 间 的 中 介 者 (调停 者 ) 。 一 切 需 服从 裁判 ， 他 才 是 
球场 的 老大 ! 


中 介 者 模式 (Mediator): 用 一 个 中 介 对 象 来 封装 一 系列 的 对 象 交互 ; 中介 者 使 各 对 象 不 需要 显 式 
地 相互 引用 ， 从 而 使 其 耦合 松散 ， 而 且 可 以 独立 地 改变 它们 之 间 的 交互 。 
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设计 模式 与 足球 (四 ) 


TR i 
设计 模式 与 足球 (四) 


行为 型 模式 (下 ) 
意大利 昨 晚 太 杯 具 了 ! ! ! 不 说 了 ， 继 续 把 最 后 一 部 分 写 完 。 


(18) 备忘录 模式 : 足球 是 圆 的， 一 切 尼 有 可 能 发 生 。 要 是 有 后 悔 药 的 话 ， 如 果 能 回 到 昨 晚 2012 
年 欧洲 杯 决 赛 的 中 场 休 息 ， 我 相信 普兰 德 利 一 定 不 会 用 莫 塔 换 下 和 蒙 托 利 沃 ; 如 果 能 回 到 昨 晚 
比赛 开始 ， 我 相信 一 开始 就 不 会 让 基 耶 利 尼 上 场 ， 如 果 能 回 到 ...... (再 回 可 能 意大利 就 被 德国 
淘汰 了 ， 微 笑 ) 能 回 到 吗 ? 回 不 到 哦 ， 要 是 能 回 到 过 去 的 话 我 还 卜 想 再 过 一 次 20 岁 (回忆 那 
段 青 获 岁 月 ) ， 可 惜 人 生 没有 后 悔 药 啊 。 幸 好 软件 系统 中 可 以 通过 备忘录 模式 来 实现 对 象 的 
状态 恢复 ， 备 忘 录 就 是 软件 中 的 后 悔 药 ， 它 就 是 软件 中 的 月 光 宝 盒 。Ctrl + Z， 撤 销 随 你 ! 


备忘录 模式 (Memento): 在 不 破坏 封装 性 的 前 提 下 ， 捕 获 一 个 对 象 的 内 部 状态 ， 并 在 该 对 象 之 
外 保存 这 个 状态 ， 这 样 以 后 就 可 将 该 对 象 恢复 到 先前 保存 的 状态 。 


(19) 观察 者 模式 : 教练 大 手 一 挥 ， 全 线 压 上 。 此 时 ， 教 练 是 观察 目标 ， 球 员 是 观察 者 ， 观 察 目 
标 与 观察 者 之 间 有 一 对 多 的 联动 ， 当 然 裁 判 也 可 以 看 成 是 球员 的 观察 目标 ， 终 场 哨 一 吹 ， 西 
班 牙 乐 成 一 片 ， 意 大 利器 成 一 片 ， 不 同 的 观察 者 反应 还 丨 的 有 所 不 同 ， 大 笑 。 


观察 者 模式 (Observer): 定义 对 象 间 的 一 种 一 对 多 的 依赖 关系 ， 以 便当 一 个 对 象 的 状态 发 生 改 变 
时 ， 所 有 依赖 于 它 的 对 象 都 得 到 通知 并 自动 更 新 。 


(20) 状态 模式 : 踢 足 球 是 要 看 状态 的 ， 当 然 状态 是 会 转换 的 。 有 的 球员 上 场 时 状态 不 行 ， 老 

是 “思考 人 生 ”， 此 时 处 于 “梦游 状态 ”; 踢 着 踢 着 状态 好 起 来 了 ， 头 顶 脚 跑 ， 运 气 好 的 话 还 能 进 
球 ， 此 时 处 于 “亢奋 状态 ”; 然后 随 着 体力 下 降 ， 动 作 变 形 ， 射 门 软 绵 无 力 ， 一 碰 就 倒 ， 此 时 又 
处 于 “体力 透支 状态 ”。 随 着 比赛 的 进行 ， 这 几 个 状态 会 发 生 转 换 ， 而 且 在 不 同 状态 下 球员 的 行 
为 也 不 同 ， 在 梦游 状态 下 基本 上 没有 射门 ， 在 亢奋 状态 下 基本 上 没有 传 球 (全 自己 射 了 ) ， 

在 体力 透支 状态 下 基本 上 没有 抢断 (自己 都 拿 不 稳 了 ， 还 抢 啥 抢 ) 。 如 果 将 每 一 种 状态 封装 

在 一 个 状态 类 中 ， 那 么 球员 就 是 拥有 状态 的 环境 类 了 。 状态 模式 (State): 允许 一 个 对 象 在 其 内 
部 状态 改变 时 改变 它 的 行为 ， 对 象 看 起 来 似乎 修改 了 它 所 属 的 类 。 


(21) 策略 模式 : 据说 1863 年 足球 刚 开 始 的 时 候 流行 1-0-9 阵 型 ，1 个 后 卫 ，9 个 前 锋 ， 木 有 越 
人 位， 惊讶 。 随 着 足球 的 发 展 ， 现 代 足 球 阵 型 的 变化 越 来 越 多 ， 面 对 防守 型 球 队 ， 可 以 选择 3-5- 
3 阵型 ， 面 对 攻击 性 强 的 球 队 ， 可 以 选择 5-4-1 阵 型 ， 当 然 还 有 经 典 的 4-4-2。 每 一 种 阵型 都 是 一 
种 策略 ， 面 对 不 同 的 对 手 可 以 选择 不 同 的 策略 。 


策略 模式 (Strategy): 定义 一 系列 的 算法 ,把 它们 一 个 个 封装 起 来 ， 并 且 使 它们 可 相互 替换 ， 策 略 
模式 使 得 算法 的 变化 可 独立 于 使 用 它 的 客户 。 


(22) 模板 方法 模式 : “角球 ! 这 是 意大利 的 机 会 ， 今 天 意大利 面 对 全 面 占 优 的 西班牙 办 法 不 

多 ， 定 位 球 可 能 是 最 有 效 的 破门 方式 了 。 皮 尔 洛 开 出 一 个 战术 角球 ， 传 给 卡 萨 诺 ， 卡 萨 诺 传 
前 点 ， 马 尔 基 西 奥 头 球 抢 点 ， 球 顶 高 了 。 不 过 这 次 角球 配合 设计 得 很 精妙 ， 给 西班牙 带 来 了 
威胁 ， 可 惜 整 场 比赛 这 种 机 会 不 多 啊 | ! ”。 在 战术 角球 中 ，A 开 球 、B 传 球 、C 抢 点 再 射门 ， 
这 是 一 个 战术 的 框架 ， 当 然 C 到 底 是 抢 前 点 还 是 抢 后 点 可 以 根据 实际 情况 来 选择 ， 如 果 将 踢 战 
术 角 球 设计 为 一 个 模板 方法 ， 那 么 每 一 个 步骤 就 是 其 中 要 调用 的 基本 方法 了 ， 而 且 在 不 同 战 
术 中 某 些 具体 步骤 的 实施 还 各 不 相同 。Perfect ! 监 是 模板 方法 模式 的 非典 型 应 用 1 


模板 方法 模式 (Template Method): 定义 一 个 操作 中 的 算法 的 骨架 ， 而 将 一 些 步骤 延迟 到 子 类 
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中 ， 使 得 子 类 可 以 不 改变 一 个 章法 的 结构 即 可 重 定义 该 工法 的 茶 些 特定 步骤 。 


(23) 访问 者 模式 : 有 些 从 事 足 球 比 赛 研究 的 人 很 喜欢 数据 。 有 的 专门 研究 一 场 比赛 中 每 个 球员 
的 跑 动 距离 ， 有 的 研究 每 个 球员 的 抢断 次 数 ， 有 的 研究 每 个 球员 的 射门 次 数 ， 有 的 研究 球员 
传 球 次 数 ， 有 的 研究 球员 传 球 成 功率 ...... 如 果 将 每 一 种 研究 类 型 看 成 一 个 访问 者 ， 那 么 球 队 就 
是 一 个 包含 多 个 队员 元 素 的 对 象 结构 ， 以 供 不 同 访问 者 来 研究 ， 微 笑 ， 当 然 ， 我 们 还 可 以 很 
方便 地 增加 新 的 访问 者 (研究 者 ) ， 例 如 ， 研 究 每 个 球员 在 比赛 中 吐 口水 的 次 数 ， 研 究 每 个 
球员 在 比赛 中 与 对 方 球员 “亲密 接触 ”次 数 ...... 


访问 者 模式 (Visitor): 表示 一 个 作用 于 茶 对 象 结构 中 的 各 元 素 的 操作 ， 可 以 在 不 改变 各 元 素 的 类 
的 前 提 下 定义 作用 于 这 些 元 素 的 新 操作 。 


因 才 下 学 浅 ， 部 分 设计 模式 的 解释 难免 有 点 牵强 ， 仅 供 大 家 茶余饭后 娱乐 娱乐 ， 请 笑 纳 ! 


456 


设计 模式 综合 应 用 实例 


设计 模式 综合 应 用 实例 
设计 模式 综合 应 用 实例 


e。 设计 模式 综合 应 用 实例 
5 这 人 人 涪 吉 射击 扩 翅 
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多 人 联机 射击 游戏 中 的 设计 模式 应 用 (一 ) 


多 人 联机 射击 游戏 中 的 设计 模式 应 用 ) 
多 人 联机 射击 游戏 中 的 设计 模式 应 用 ) 


为 了 方便 大 家 更 加 系统 地 学 习 和 掌握 各 种 常用 的 设计 模式 ， 下 面 通过 一 个 综合 实例 一 “多 人 
联机 射击 游戏 ”来 学 习 如 何在 实际 开发 中 综合 使 用 设计 模式 。 


( 二 
( a 


反 丽 精英 (Counter-Strike, CS)、 三 角 洲 部 队 、 战 地 等 多 人 联机 射击 游戏 广 受 玩家 欢迎 ， 在 多 人 
联机 射击 游戏 的 设计 中 ， 可 以 使 用 多 种 设计 模式 。 下 面 我 选取 一 些 较为 常用 的 设计 模式 进行 
分 析 : 


(1) 抽象 工厂 模式 


在 联机 射击 游戏 中 提供 了 多 种 游戏 场景 ， 不 同 的 游戏 场景 提供 了 不 同 的 地 图 、 不 同 的 背景 音 
乐 、 不 同 的 天 气 等 ， 因 此 可 以 使 用 抽象 工厂 模式 进行 设计 ， 类 图 如 图 1 所 示 : 


SceneFactory 







+ createMap () : Map 

+ createMusic()  : Music 

+ createW eather () : Weather 
a 





+ createM ap () + createMap() : Map 
+ createMusic () : i + createMusic () :Music 
+ createW eather () : Weather + CredteWeather () : Weather 


El 


图 1 抽象 工厂 模式 实例 类 图 
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在 图 1 中 ，SceneFactory 充 当 抽 象 工 厂 ， 其 子 类 SceneAFactory 等 充当 具体 工厂 ， 可 以 创建 具体 
的 地 图 (Map)、 背 景 音乐 (Music) 和 天 气 (Weather) 等 产品 对 象 ， 如 果 需 要 增加 新 场景 ， 只 需 增加 
新 的 具体 场景 工厂 类 即 可 。 


(2) 建造 者 模式 


。 色 都 需要 提供 一 个 完整 的 角色 造型 ， 包 括 人 物 造型 、 服 
、 武 器 等 ， 可 以 使 用 建造 者 模式 来 创建 一 个 完整 的 游戏 角色 ， 类 图 如 图 2 所 示 : 





图 2 建造 者 模式 实例 类 图 


在 图 2 中 ，PlayerCreatorDirector 充 当 指 挥 者 角色 ，PlayerBuilder 是 抽象 建造 者 ， 其 子 类 

， 用 于 创建 不 同 的 游戏 角色 ，Player 是 所 创建 的 
整 产品 ， 即 完整 的 游戏 角色 ， 它 包含 形体 (body)、 服 装 (costume) 和 武器 (weapom 等 组 成 部 

o 

(3) 工厂 方法 模式 

在 射击 游戏 中 ，AK47 冲 锋 步 检 、 狙 击 枪 、 手 枪 等 不 同 武器 (Weapom) 的 外 观 、 使 用 方法 和 杀伤 


力 都 不 相同 ， 玩 家 可 以 使 用 不 同 的 武器 ， 而 且 游 戏 升 级 时 还 可 以 增加 新 的 武器 ， 无 需 对 现 有 
系统 做 太 多 修改 ， 可 使 用 工厂 方法 模式 来 设计 武器 系统 ， 类 图 如 图 3 所 示 : 
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二 Weapon 


和 WeaponFactory + display () : void 





+ Use () : void 
+ fire () : void 











|+ createWeapon () : Weapon 
A 


AK47Gun SniperRifle 
SniperRifeFactory | .| 
| | [rdisplay () :void| |+ display () :void 


+ Use () :Void| |+ use() : void 





+ fire () :Void| |+ fire () : void 











图 3 工厂 方法 模式 实例 类 图 


在 图 3 中 ，WeaponFactory 接 口 表示 抽象 武器 工厂 ， 其 子 类 AK47GunFactory 生 产 AK47Gun ， 
SniperRifleFactory 生 产 SniperRifle， 不 同 的 武器 的 display()、use() 和 fire() 等 方法 有 不 同 的 实现 。 


(4) 迭代 器 模式 
在 射击 游戏 中 ， 一 个 玩家 可 以 拥有 多 种 武器 ， 如 既 可 以 拥有 AK47 冲 锋 枪 ， 还 可 以 拥有 手枪 和 


七 首 ， 因 此 系统 需要 定义 一 个 弹药 库 (武器 的 集合 ) ， 在 游戏 过 程 中 可 以 遍历 弹药 库 
(Magazinej， 选 取 合适 的 武器 ， 在 遍历 弹药 库 时 可 使 用 迭代 器 模式 ， 如 类 图 如 图 4 所 示 : 









Magazine 
- weapons : ArrayList 
- iterator  : lterator 


+ Magazine () 
+ display () 











: voId 





4 迭代 器 模式 实例 类 图 
在 类 Magazine 中 ， 可 以 通过 和 迭代 器 遍历 弹药 库 ，Magazine 类 的 代码 片段 如 下 所 示 : 


public class Magazine { 
private ArrayList weapons ; 
private Iterator Iterator ; 


public Magazine() { 
weapons = new ArrayList(); 
iterator = weapons.iterator(); 


} 
public void display() { 
while(iterator.hasNext()) { 
((Weapon)iterator.next()).display(); 
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多 人 联机 射击 游戏 中 的 设计 模式 应 用 (一 ) 


除了 遍历 弹药 库 外 ， 和 迭代 器 模式 还 可 以 用 于 遍历 战队 盟友 等 聚合 对 象 。 
(5) 命令 模式 
在 射击 游戏 中 ， 用 户 可 以 自 定义 快捷 键 ， 根 据 使 用 习惯 来 设置 快捷 键 ， 如 “W” 键 可 以 设置 


为 “ 开 枪 ”的 快捷 键 ， 也 可 以 设置 为 “前 进 ” 的 快捷 键 ， 可 通过 命令 模式 来 实现 快捷 键 设置 ， 类 图 
如 图 5 所 示 : 






ShortcutKey 
- commands : Command[] 


Command 


上 + execute () : void| 
二 












+ press (int keycode) 














GoAheadCommand 
- obj : GoAheadHandler 






-execute () :void | 


obj.action(); 





obj.action(); 











ShotHandler 


GoAheadHandler 
+ action () : void i 


ee 


图 5 命令 模式 实例 类 图 在 图 5 中 ，ShortcutKey 充 当 请 求 调用 者 ， 在 其 press() 方 法 中 将 判断 用 户 
按 的 是 哪个 按键 ， 再 调用 命令 对 象 的 execute() 方 法 ， 在 具体 命令 对 象 的 execute() 方 法 中 将 调用 
接收 者 如 ShotHandler、GoAheadHandler 的 action() 方 法 来 执行 具体 操作 。 在 实现 时 可 以 将 具体 
命令 类 类 名 和 键盘 按键 的 键 码 (Keycode) 存 储 在 配置 文件 中 ， 配 置 文件 格式 如 下 所 示 : 


<FunctionMapping keycode="87" commandClass="ShotCommand"/> 
<FunctionMapping keycode="38" commandClass="GoAheadCommand"/> 


如 果 需 要 更 换 快捷 键 ， 只 需 修 改 键 码 和 具体 命令 类 的 映射 关系 即 可 ; 如 果 需 要 在 游戏 的 升级 
版 本 中 增加 一 个 新 功能 ， 只 需 增 加 一 个 新 的 具体 命令 类 ， 可 通过 修改 配置 文件 来 为 其 设置 对 
应 的 按键 ， 原 有 类 库 代码 无 需 任 何 修改 ， 很 好 地 符合 开 闭 原则 。 
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多 人 联机 射击 游戏 中 的 设计 模式 应 用 (二 ) 
多 人 联机 射击 游戏 中 的 设计 模式 应 用 (二 ) 


(6) 观察 者 模式 


联机 射击 游戏 可 以 实时 显示 队友 和 敌人 的 存活 信息 ， 如 果 有 队友 或 敌人 阵亡 ， 所 有 在 线 游戏 
玩家 将 收 到 相应 的 消息 ， 可 以 提供 一 个 统一 的 中 央 角 色 控 制 类 (CenterController) 来 实现 消息 传 
递 机 制 ， 在 中 央 角 色 控 制 器 中 定义 一 个 集合 用 于 存储 所 有 的 玩家 信息 ， 如 果 某 玩家 角色 
(Player) 阵 亡 ， 则 调用 CenterController 的 通知 方法 notifyPlayers()， 该 方法 将 遍历 用 户 信息 集 

合 ， 调 用 每 一 个 Player 的 display() 方 法 显示 阵亡 信息 ， 队 友 阵 亡 和 敌人 阵亡 的 提示 信息 有 所 不 
同 ， 在 使 用 notifyPlayers(0) 方 法 通知 其 他 用 户 的 同时 ， 阵 亡 的 角色 对 象 将 从 用 户 信息 集合 中 被 
删除 。 可 使 用 观察 者 模式 来 实现 信息 的 一 对 多 发 送 ， 类 图 如 图 6 所 示 : 


+ die () 
+ displayTeam (String name) : void 
+ displayEnemy (String name) : void 
+ detach (Observer obs) :void + getName () : String 
+ attach (Observer obs) | :void + setName (String name) : void 
+ notifyPlayers (String name, String type) : void + getType () 


+ setType (String type) : void 
A 















CenterController 
- players : ArrayList 


+ CenterController () 















- name : String 

- type : String 

ene - controller : CenterController 
controller.attach(this); + Player (String name, String type, 


CenterController controller) 


controller notifyPlayersnametye) | |+ die() 
| | + displayTeam (String name) 


+ displayEnemy (String name) 
+ getName () 

+ setName (String name) 

+ getType () 

+ setType (String type) 








图 6 观察 者 模式 实例 类 图 


在 图 6 中 ，CenterController 充 当 观 察 目 标 ，Observer 充 当 抽 象 观察 者 ，Player 充 当 具 体 观 察 者 。 
在 Player 类 中 ，name 属 性 表示 角色 名 ，type 属 性 表示 角色 类 型 ， 如 “战队 A” 或 “战队 B” 等 。 
Player 的 die() 方 法 执行 时 将 调用 CenterController 的 notifyPlayers() 方 法 ， 在 notifyPlayers() 方 法 中 
调用 其 他 Player 对 象 的 提示 方法 ， 如 果 是 队友 阵亡 则 调用 displayTeam()， 如 果 是 敌人 阵亡 则 调 
用 displayEnemy() ; 还 将 调用 detach() 方 法 删除 阵亡 的 Player 对 象 ， 其 中 CenterController 类 的 
notifyPlayers() 方 法 代码 片段 如 下 所 示 : 


for(Object player : players) { 
if(player.getName().equals(name)) { 
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this.detach(player); // 删 除 阵亡 的 角色 


} 
else { 
if(player.getType().equals(type)) { 
player .displayTeam(name); // 队 友 显 示 提 示 信 息 
else { 
player .displayEnemy(name); // 笋 人 显示 提示 信息 
} 


} 
(7) 单 例 模 式 
为 了 节约 系统 资源 ， 在 联机 射击 游戏 中 可 以 使 用 单 例 模 式 来 实现 一 些 管理 器 (Manager)， 如 场 


景 管理 器 (SceneManager)、 声 音 管理 器 (SoundManager) 等 ， 如 图 7 所 示 的 场景 管理 器 
SceneManager 类 : 








SceneManager 
- SManager : SceneManager 


- SceneManager () 
+ getSceneManager () : SceneManager 
+ manage () : Void 









图 7 单 例 模 式 实例 类 图 
SceneManager 类 的 实现 代码 片段 如 下 所 示 【 注 : 以 下 代码 未 考虑 多 线程 访问 的 问题 】 


class SceneManager { 
private static SceneManager sManager = null; 


private SceneManager() { 
// 初 始 化 代码 
} 


public synchronized static SceneManager getInstance() { 
if(sManager==null1) { 
sManager = new SceneManager(); 
} 


return sManager,; 
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public void manage() { 
// 业 务 方法 
} 


} 
(8) 状态 模式 


在 射击 游戏 中 ， 游 戏 角色 存在 几 种 不 同 的 状态 ， 如 正常 状态 、 暂 停 状 态 、 阵 亡 状 态 等 ， 在 不 
同 状态 下 角色 对 象 的 行为 不 同 ， 可 使 用 状态 模式 来 设计 和 实现 角色 状态 的 转换 ， 类 图 如 图 8 所 
示 : 





























State 
- State : State abd 
ee pn er # player :Player 
+ Player (String name, int lifeValue) # lifeValue .int 
+ SetState (State state) :void et .。 
+ pause () :void Do: 2 
+ Start () :void :vol 
+ beAttacked () :void ee () :void 
+ Shot () void shot () 
+ move() void move () 





























NormalState PauseState DeathState 

+ NormalState (State state) + PauseState (Player player, + DeathState (State state) 
+ pause () :void int lifeValue) + pause () :void 
+ Sstart () :void ||+ PauseState (State state) + Start () :void 
+ beAttacked () :Void ||+ pause () :void | + beAttacked () :void 
+ Shot () :void |l+ start () :void ||+ shot () :void 
+ move () :void |+ beAttacked () :void ||+ move () :void 
|+ shot() :void 

+ move () :void 





图 8 状态 模式 实例 类 图 

在 图 8 中 ， 游 戏 角色 类 Player 充 当 环 境 类 ，State 充 当 抽 象 状态 类 ， 其 子 类 NormalState、 
PauseState 和 DeathState 充 当 具 体 状 态 类 ， 在 有 具体 状态 类 的 pause()、start()、beAttackedO 〇 等 方法 
中 可 实现 状态 转换 ， 其 中 NormalState 类 的 代码 片段 如 下 所 示 : 


class NormalState extends State 
{ 
public void pause() // 游 戏 暂 停 


// 暂 停 代码 省 略 
player.setState(new PauseState(this)); // 转 为 暂停 状态 


ne void start() // 游 戏 启动 
// 游 戏 程序 正在 运行 中 ， 该 方法 不 可 用 
void beAttacked() // 被 攻击 
// 其 他 代码 省 略 
en, 


} 


player .setState(new Deathstate(this)); // 转 为 阵亡 状态 
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ee void shot() // 射 击 
// 代 码 省 略 
public void move() // 移 动 
// 代 码 省 略 
} 
(9) 适配器 模式 
为 了 增加 游戏 的 灵活 性 ， 某 些 射击 游戏 还 可 以 通过 游戏 手柄 来 进行 操作 ， 游 戏 手柄 的 操作 程 
序 和 驱动 程序 由 游戏 手柄 制造 商 提供 ， 为 了 让 当前 的 射击 游戏 可 以 与 游戏 手柄 兼容 ， 可 使 用 
适配器 模式 来 进行 设计 ， 类 图 如 图 9 所 示 : 


GameController 





+ move () : void 
+ shot() :void 
+ jump () :void 



















+ handle () 
ZA 


GamepadsAdapter 
- keys : GamepadsKey!] 
+ GamepadsAdapter (GamepadsKey![] keys) 

















+ move () : void 
+ shot () :void | 
+ jump () :void | |+ handle () | |+ handle () | |+ handle () 





图 9 适配器 模式 实例 类 图 


在 图 9 中 ，GamepadsAdapter 充 当 适 配器 ， 它 将 游戏 手柄 中 按键 (GamepadsKey) 的 方法 适 配 到 现 
有 系统 中 ， 在 其 move() 方 法 中 可 以 调用 MoveKey 类 的 handle() 方 法 ， 在 其 shot() 方 法 中 可 以 调用 
ShotKey 的 handle() 方 法 ， 从 而 实现 通过 手柄 来 控制 游戏 运行 。 
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设计 模式 综合 实例 分 析 之 数据 库 同 步 系统 (一 ) 


设计 模式 综合 实例 分 析 之 数据 库 同步 系统 
(—) 

设计 模式 综合 实例 分 析 之 数据 库 同步 系统 
(= 


最 近 有 很 多 朋友 跟 我 聊 到 关于 “在 软件 项 目 开 发 中 如 何 合理 使 用 设计 模式 ”的 问题 ， 和 希望 我 能 够 
给 出 一 些 相 对 比较 完整 的 真实 项 目 实例 ， 为 了 满足 大 家 的 要 求 ， 在 后 续 文章 中 ， 我 将 拿 出 几 
个 较为 复杂 的 实例 与 大 家 一 起 分 享 ， 有 些 项 目 是 我 参与 开发 的 ， 有 些 项 目 是 在 我 的 指导 下 开 
发 的 ， 和 希望 能 给 大 家 带 来 帮助 ! 在 此 我 也 希望 大 家 能 够 分 享 自己 的 一 些 设计 模式 使 用 心得 和 
好 的 设计 模式 应 用 实例 ， 可 以 整理 一 份 给 我 (可 发 送 到 邮箱 : weiliu_china@126.com) ， 在 下 
一 本 设计 模式 图 书 (有 计划 明年 写 一 本 《设计 模式 案例 剖析 》， 暂 定名 ) 中 我 将 选取 部 分 实 
例 加 入 其 中 ， 如 有 入 选 者 ，Sunny 承 诺 送 签名 图 书 两 本 ， 选 择 范 围 包括 已 经 出 版 的 《设计 模 
式 》、《 设 计 模 式 实 训 教程 》、《 设 计 模 式 的 艺术 》， 还 包括 马上 要 出 版 的 《C# 设 计 模 式 》 
和 正在 编写 的 《UML 建 模 实 训 教程 》， 任 君 挑选 ， 正 版 保证 ， 假 一 罚 十 ! 


从 本 文 开 始 ， 我 将 介绍 一 个 数据 库 同 步 系 统 的 设计 方案 ， 该 系统 是 我 在 2010 年 给 某 软 件 
为 了 在 数据 库 发 生 故 障 的 情况 下 不 影响 核心 业务 的 运行 ， 需 要 将 生产 数据 库 定 期 备份 到 开 
系统 目前 需求 仅 要 求 支持 Orac1le 数 据 库 的 同步 ， 但 系统 设计 时 需要 考虑 以 后 可 以 方便 地 支 : 










加 载 同步 参数 数据 


同步 名 发 器 同步 物化 视图 













同步 同义词 


同步 序列 






图 1 数据 库 同 步 流 程 图 
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设计 模式 综合 实例 分 析 之 数据 库 同 步 系统 (一 ) 


数据 库 同步 系统 界面 如 图 2 所 示 : 


数据 库 同 步 
步 职 名 称 ”数据 库 网 步 
源 数据 库 连 接 
目标 数据 库 连 接 
控制 数据 库 连 接 


数据 库 对 象 类 型 
回 表 

回 视图 

回 序列 

回 包 


加 存储 过 程 
加 函数 

加 同义词 
回 分 区 表 
[¥] DB Link 
回 物化 视图 





指定 而 同步 表 SQL 








图 2 数据 库 同 步 系统 界面 

用 户 在 操作 界面 指定 源 数据 库 、 目 标 数 据 库 、 控 制 数据 库 (用 于 读 取 配置 信息 ) 的 数据 库 连 
接 串 ， 同 时 选取 需要 同步 的 数据 库 对 象 类 型 ， 对 象 类 型 存储 在 配置 文件 
database_syn_config.xml 中 ， 通 过 输入 SQL 语 名 可 以 获取 需要 同步 的 表 数 据 。 

数据 库 对 象 同步 的 处 理 逻 辑 描述 如 下 : 


(1) 对 于 一 般 的 数据 库 对 象 ， 同 步 时 先 取 出 源 数据 库 与 目标 数据 库 该 类 数据 库 对 象 进 行 对 比 ， 
然后 将 对 象 更 新 到 目标 数据 库 。 


(2) 对 于 DBLink 对 象 ， 由 于 数据 库 环境 发 生 交 化 ， 需 要 手工 调整 ， 同 步 过 程 只 记录 新 增 的 
DBLink 信 息 ， 而 不 执行 创建 操作 。 


(3) 表 的 同步 处 理由 于 其 包含 数据 ， 因 此 较为 特殊 ， 需 先 对 表 结 构 变 化 进行 分 析 ， 再 同步 数 
据 。 表 数据 的 同步 有 三 种 方式 : 增 量 同步 、 先 Delete 后 Insert 方 式 、 临 时 表 方式 。 


(DD 增 量 同步 。 适 用 于 可 确定 最 后 修改 时 间 惟 字段 的 情况 。 
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设计 模式 综 分 析 之 数据 库 同步 系统 (一 ) 


(ID) 先 Delete 后 Insert 方 式 。 即 先 删 除 表 的 数据 ， 再 将 源 数据 库 的 该 表 数 据 插入 到 目标 数据 库 ， 
为 确保 数据 安全 ， 要 求 在 一 个 事务 内 完成 。 


(IID 临时 表 方式 。 用 于 最 大 限度 保证 数据 的 完整 性 ， 是 一 种 在 发 生意 外 情况 时 ， 不 丢失 数据 而 
使 用 的 较为 复杂 的 方式 。 


由 于 对 数据 库 结 构 修 改 无 法 做 事务 回 滚 ， 因 此 如 果 后 面 的 步骤 发 生 异 常 ， 需 要 通过 手工 编码 
方式 来 实现 目标 数据 库 结构 变化 的 回 滚 。 


在 本 系统 实现 过 程 中 使 用 了 多 种 设计 模式 ， 下 面 对 其 进行 简要 分 析 (为 了 简化 代码 和 类 图 ， 
省 略 了 关于 包 的 描述 ， 在 实际 应 用 中 已 将 不 同 的 类 封装 在 不 同 包 中 ) : 


1. 建造 者 模式 


在 本 系统 实现 时 提供 了 一 个 数据 库 同步 流程 管理 器 DBSynchronizeManager 类 ， 它 用 于 负责 控制 
数据 库 同 步 的 具体 执行 步骤 。 用 户 在 前 全 界面 可 以 配置 同步 参数 ， 程 序 运行 时 ， 需 要 根据 这 
些 参数 来 创建 DBSynchronizeManager 对 象 ， 创 建 完 整 DBSynchronizeManager 对 象 的 过 程 由 类 
DBSynchronizeManagerBuilder 负 责 ， 此 时 可 以 使 用 建造 者 模式 来 一 步 一 步 构 造 一 个 完整 的 复杂 
对 象 ， 类 图 如 图 3 所 示 : 





0 DBSynchronizeManager 
+ initParam( 2V 
SynchronzeParaminfo synchronzeParamirf 

0) 
















+ construct ( : DBSynchronzeM anager 
YP synchronizeParaminf 
0 









# Synchronizers : List<DBObjectSynchronizer> = new ArrayList<DBObjectSynchronzer>() 
# srcDB : Database 
# destDB : Database 
网 ctriDB : Database 
* synDataTableConfigs : Map<String, SynDataTableConfig> 
+ getSrcDB (0) : Database 
+ SetSrcDB (Database srcDB) :void 
tDestDB : Database 
:void 
: Database 
+ SetCtriDB (Database ctrIDB) :void 
+ getSynDataTableConfigs 0) : Map=String, SynDataTableConfig= 
+ setSynDataTableConfigs (Map<String，: void 
SynDataTableConfig> 
synDataTableConfigs) 
+ attachDBSynchronizer ( 
DBObjectSynchronizer dbSynchronizer) 
+ detachDBSy nchronizer ( :Vo 
DBObjectSynchronizer ne 


图 3 建造 者 模式 实例 类 


在 图 3 中 省 略 了 抽象 建造 者 ，DBSynchronizeManagerDirector 充 当 指 挥 者 类 ， 
DBSynchronizeManagerBuilder 充 当 建 造 者 ， DBSynchronizeManager 充 当 复 杂 产 品 。 
1. 简单 工厂 模式 


DBSynchronizeManagerBuilder 类 的 buildLife() 方 法 可 以 创建 一 个 初始 的 DBSynchronizeManager 
实例 ， 再 一 步 一 步 为 其 设置 属性 ， 为 了 保证 在 更 换 数 据 库 时 无 须 修改 
DBSynchronizeManagerBuilder 类 的 源 代码 ， 在 此 处 使 用 简单 工厂 模式 进行 设计 ， 将 数据 库 类 型 
存储 在 配置 文件 中 ， 如 下 片段 代码 所 示 : 


设计 模式 综合 实例 分 析 之 数据 库 同步 系统 (一) 


<dbSynchronizeManager dbType="oracle" class="com. chinacreator.dbSyn 


类 图 如 图 4 所 示 : 


DBSynchronizeManager 





# Synchronizers : List<DBObjectSynchronizer> = newArrayList<DBObjectSynchronizer>() 
: Database 
: Database 
: Database 

* synDataTableConfigs : Map<String, SynDataTableConfig> 

+ getSrcDB () :Database 

+ setSrcDB (Database srcDB) :void 

+ getDestDB 0 : Database 


DBSynchronizeManagerFactory + setDestDB (Database destDB) :void 
+ getCtriDB () Database 


+ factory (String dbType) : DBSynchronizeManager + setCtrDB (Database ctriDB) :void 


+ getSynDataTableConfigs () : Map<String, SynDataTableC onfig> 
+ setSynDataTableConfigs (Map<String，: void 
SynD ataTableCorfig> 
synDataTableConfigs) 
+ attachDBSynchronizer ( :void 
DBObjectSynchronizer dbSynchronizer) 
+ detachDBSynchronizer ( -void 
DBObjectSynchronizer dbSynchronizer) 
+ executeSyn 0 :void 











OracleDBSynchronizeManager 


+ executeSyn() :void 
# synDBObject() :void 
# compileDBObject 0 : void 







4 简单 工厂 模式 实例 类 图 
使 用 简单 工厂 模式 设计 的 工厂 类 DBSynchronizeManagerFactory 代 码 如 下 所 示 : 


public class DBSynchronizeManagerFactory { 
public static DBSynchronizeManager factory(String dbType) throws 
String className = DBSynConfigParser.getSynchronizeManagerCcl 
return (DBSynchronizeManager)Class.forName(className).newIns 


其 中 i 用 于 读 取 配置 文件 ， 在 图 4 中 ，DBSynchronizeManagerFactory 类 充当 
数据 库 同步 流程 管理 器 的 简单 工厂 ，DBSynchronizeManager 是 抽象 产品 ， 而 
dn 具体 产品 。 
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设计 模式 综合 实例 分 析 之 数据 库 同 步 系统 (二 ) 


计 模 式 综合 实例 分 析 之 数据 库 同 步 系统 


) 
计 模 式 综合 实例 分 析 之 数据 库 同 步 系统 


接 “ 设 计 模 式 综合 实例 分 析 之 数据 库 同 步 系 统 (一 ) “。 
1. 享 元 模式 和 单 例 模 式 


在 数据 库 同步 系统 中 ， 抽 和 象 类 DBObjectSynchronizer 表 示 需 要 同步 的 数据 库 对 象 ， 对 于 不 同 的 
数据 库 对 象 类 型 ， 提 供 了 不 同 的 子 类 实现 ， 在 数据 库 同 步 时 可 能 有 多 个 线程 在 同时 进行 同步 
工作 ， 为 了 节省 系统 资源 ， 可 以 使 用 享 元 模式 来 共享 DBObjectSynchroizer 对 象 ， 提 供 了 享 元 工 
厂 类 DBObjectSynchronizerFlyweightFactory， 且 享 元 工厂 类 使 用 单 例 模式 实现 ， 类 图 如 图 5 所 
示 













instance 


DBObjectSynchronizer 
{abstract} 
# objectTypeC ode : Strin 
DBObjedSynchronize rf lyweightFactory 日 ble val ai : String 


- instance :DBObjectSynchronizerFlyweightr actory = newDBObjecisynchronizerF lyweightFacory() + getobjectTypeC ode () 
- map :Map<String, DBObjectSynchronizer> = newHashM ap<String, DBObjedSynchronizer>() + setObjectTypeC ode ( 

- <<Construdor>> DBObjectSynchronizerF lyweightFactory () String objectTypeC ode) 

+ getinstance () :DBObjedSynchronizerF lyweightF actory 
+ factory ( :DBObjedSymchronizer 

















DBObjectSynchronizerMeta dbO bjectSynchro String objectTypeLable) 

nizerM eta) E . ly + processSyn( = 
buildDBObje dSynchronizer ( :DBObjedSsymnchronizer DBSynchronizeM anager dbSynchronizeManage 
DBObjectSynchronizerMeta dbO bjectS ynchro 


nizerMeta) 











DeBultOracle ObjectS ynchronizer 


+ processSyn( :woid 
DBSynchronizeM anager dbSynchronize Manage 











n) 

+ compile( 2 
DBSynchronizeM anager dbSynchronize Manage 
n) 

# getC omopileable () 












String dbObjName) 
人 
OracleTableD BSynchronizer 


OracleD BlinkD BSynchronizer + <<Overide>> processSyn( - 


EN | DBSynchronizeManager dbSynchronize Manage 


+ <<Overide>> processSyn ( :void 
DBSynchronizeManager dbS ynchronizeManage 
D) 

















n) 
indAlrrables (Database database) 
synSingleTable (StrngtableName， 


大 
基 < 
DBSynchronizeM anager dbSynchronizeManag 





er) 


图 5 享 元 模式 和 单 例 模 式 实例 类 图 


在 图 5 中 ，DBObjectSynchronizerFlyweightFactory 充 当 数 据 库 对 象 同步 执行 者 的 享 元 工厂 ， 同 
步 对 象 执 行 类 DBObjectSynchronizer 充 当 抽 象 享 元 ， 其 间接 子 类 OracleDBlinkDBSynchronizer、 
OracleTableDBSynchronizer 等 充当 具体 享 元 〈 由 于 篇 幅 问 题 ， 未 将 所 有 数据 库 对 象 类 一 一 列 
出 ) 。 


在 实现 DBObjectSynchronizerFlyweightFactory 时 使 用 了 单 例 模 式 〈 饿 汉 式 单 例 ) ， 其 代码 片段 
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设计 模式 综合 实例 分 析 之 数据 库 同 步 系 统 (二 ) 


如 下 所 示 : 


public class DBObjectSynchronizerFlyweightFactory { 
private static DBObjectSynchronizerFlyweightFactory instance = nt 
private Map<String, DBObjectSynchronizer> map = new HashMap<Stri 
private DBObjectSynchronizerFlyweightFactory()t{ } 
public static DBObjectSynchronizerFlyweightFactory getInstance() 
return instance; 


1， 观察 者 模式 


在 数据 库 同步 系统 中 ， 用 户 可 以 自行 决定 需要 同步 哪些 对 象 ， 需 要 同步 的 
DBObjectSynchronizer 子 类 对 象 将 注册 到 DBSynchronizeManager 中 ，DBSynchronizeManager 类 
的 代码 片段 如 下 所 示 : 


public abstract class DBSynchronizeManagert 
public void attachDBSynchronizer(DBObjectSynchronizer dbSynchron 
synchronizers.add(dbSynchronizer); 


public void detachDBSynchronizer (DBObjectSynchronizer dbSynchron 
Synchronizers,remove(dbSynchronizer )， 


public abstract void executeSyn() throws Exception; 
其 中 attachDBSynchronizer(DBObjectSynchronizerdbSynchronizer) 为 注册 方法 ， 
detachDBSynchronizer(DBObjectSynchronizerdbSynchronizer) 为 注销 方法 ，executeSyn() 为 抽象 


的 通知 方法 ， 其 子 类 OracleDBSynchronizeManager 为 executeSyn() 方 法 提供 了 具体 实现 ， 类 图 如 
图 6 所 示 : 
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DBSychronizeMana ger 





:List<DBObje dSynchronizer> = newArrayList<DB ObjectS ynchronizer>0 


:Database 
:Database 
:Database 
* synDataTableConfigs : Map<String, SynDataTableC onfig> 
+ getSrcDB 0 :Database 
+ setSrcDB (Database srcDB) :void 
+ getDestDB 0 :Database 
+ selDestDB ID atabase destD 6) :void 
+ getCtiDB 0 :Database 
+ setctrIDB Database drDB) :woid 
+ getSynDataTableConfigs 0 :Map<String, SynD ataTableConfig> 
+ setsynDataTableConfigs Map<String, :void 
SynD ataTableConig> 
synDataTableConigs) 
+ attachDBSynchronizer ( :woid 
DBObjedSynchronizer dbSynchronizer) 
+ detachDBSynchronizer( 
DBObiedS ychonizor dbSynetroniann) 
+ executeSyn 0 


QOradeD BSynchronizeMana ger| 


图 6 观察 者 模式 实例 类 图 












{abstract} 
# objectTypeLable : Sting 
+ getDbjecTypeCode () 
+ setObjectTypeC ode ( 
String objectTypeCode) 
+ getDbjectTypeLable () 
+ setObjeciTypeLable ( 
String objectTypeLable) 
+ processSyn( S 
DBSychronizeManagerdbSywchronizeManage 





+ processSyn( :void 
DBSynchronizeManagerdbSychronizeManage 


DBSynchronizeM anager dbS nchronizeM anage 
中) 
# getcompileable () 







String dbObjName) 






OradeTableDBSynchronizer 
+ <<Overide>> processSyn ( :void 
DBSynchronizeM anager dbS nchronizeManage 














n) 

findAlTables (Database database) 
synSingleTable (String tableName, 
DBSynchronizeManager dbSynchronizeManag 
en 









入 入 


: Stringl 
:void 






在 数据 库 同步 时 ， 如 果 DBSynchronizeManager 的 executeSyn() 方 法 被 调用 ， 将 遍历 观察 者 集 

合 ， 调 用 re 象 的 executeSyn() 方 法 和 compileDBObjectO 方 法 ， 此 时 
DBSynchronizeManager 充 当 抽 象 观察 目标 ，OracleDBSynchronizeManager 充 当 具 体 观 察 目标 ， 
DBObjectSynchronizer 充 当 抽 象 观察 者 ，OracleTableDBSynchronizer 充 当 具 体 观 察 者 。 


1. 模板 方法 模式 


在 执行 同步 时 ，OracleDBSynchronizeManager 的 executeSyn() 方 法 将 依次 调用 synDBObject() 和 
compileDBObject() 方 法 ， 并 在 这 两 个 方法 中 分 别 调用 DBObjectSynchronizer 的 processSyn() 和 
compile() 方 法 ， 在 OracleDBSynchronizeManager 的 子 类 中 可 以 覆盖 synDBObject() 和 


compileDBObjectO 方 法 ， 如 图 7 所 示 : 
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设计 模式 综 例 分 析 之 数据 库 同 步 系统 (二) 






OracleDBSynchronizeManager 


+ executeSyn () :void 
# synDBObject() :void 
# compileDBObject() :void 









NewOracleDBSynchronize Manager 


# synDBObject() :void 
# compileDBObject() :void 






图 7 模板 方法 模式 实例 类 图 


在 图 7 中 ，OracleDBSynchronizeManager 充 当 抽 象 父 类 ， 其 中 定义 了 模板 方法 executeSyn() ， 
NewOracleDBSynchronizeManager 充 当 具 体 子 类 ， 其 中 OracleDBSynchronize Manager 的 代码 片 
段 如 下 所 示 : 


public class OracleDBSynchronizeManager extends DBSynchronizeManager 
public void executeSyn() throws Exception { 
synDBObject( ); 
compileDBObject( ); 
} 
protected void synDBObject()t{ 
for (DBObjectSynchronizer dbSynchronizer : synchronizers) { 
try { 
dbSynchronizer .processSyn(this); 
} catch (Exception e) { 
e.printStackTrace( ); 


} 
} 
} 
protected void compileDBObject()t{ 
for (DBObjectSynchronizer dbSynchronizer : synchronizers) { 


try { 
dbSynchronizer .compile(this); 


} catch (Exception e) { 
e.printStackTrace( ) ; 


} 


} 


由 于 Oracle 数 据 库 对 象 类 型 较 多 ， 而 大 部 分 对 象 的 处 理 逻 辑 大 同 小 剧 ， 只 有 少 部 分 对 输 类 型 同 
步 结 构 后 需要 重新 编译 ， 因 此 在 设计 DefaultOracleObjectSynchronizer 类 时 也 可 以 使 用 模板 方法 
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模式 ， 在 其 中 定义 一 个 钓 子 方法 getCompileable()， 由 子 类 决定 是 否 要 调用 编译 逻辑 ， 代 码 片 
段 如 下 所 示 : 


public class DefaultOracleObjectSynchronizer extends DBObjectSynchro 
public void compile(DBSynchronizeManager dbSynchronizeManager) 

throws Exception { 

if (getCompileable())t{ 
Database destDB = dbSynchronizeManager ,getDestDB( ) ; 
String[] compileobjs = findAllobjects(destDB); 
int iLen = compileO0bjs.1length; 
for (int i = 0; i < iLen; i++) { 

compileObject(destDB, compileObjs[i]); 
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设计 模式 综合 实例 分 析 之 数据 库 同 步 系 统 (三 ) 


受 计 模式 综合 实例 分 析 之 数据 库 同 步 系 统 
(=) 


设计 模式 综合 实例 分 析 之 数据 库 同步 系统 
接 “ 设 计 模 式 综合 实例 分 析 之 数据 库 同步 系统 (二 )“。 
1. 策略 模式 
由 于 表 数 据 的 同步 方式 有 三 种 ， 分 别 是 增 量 同步 、 先 Delete 后 Insert 方 式 、 临 时 表 方 式 ， 因 此 可 


以 定义 一 个 同步 策略 接口 DataSynStrategy， 并 提供 三 个 具体 实现 类 : IncSynStrategy、 
DelAndInsSynStrategy 和 TempTableSynStrategy。 类 图 如 图 8 所 示 : 











OracleTableDBSynchronizer 


DataSynStrategy 

















+ <<Override>> processSyn( :void 


DBSynchronizeM anager dbSynchronzeM anage iene 
站) 


# srcDB : Database 

# destDB :Database 

+ <<Constructor>> DataSynStrategy (String tableName， 
Database srcDB, Database ny 

+ proc: n 








基 findAlITables (Database database) : String[ 
基 synSingleTable (String tableName, :void 
DBSynchronzeManager dbSynchronizeManag 
er) 





















IncSynStrategy TenmpTableSynStrategy 
+ <<Constructor>> IncSynStrategy (String tableName, + <<Construdor>> TempTable SynStrategy (String tableName, 
Database srcDB, Database destDB) Database srcDB, Database destDB) 
+ <<COVerride>> processSyn() : String + <<Dverride>> ”processSyn0 :String 
- generateTempTableName () :String 





DelAndinsSyrStrategy 


+ <<Constructor>> DelAndinsSynStrategy (String tableName, 
Database srcDB, Database desDB) 
党 processSyn0 :String 





图 8 策略 模式 实例 类 图 


在 图 8 中 ，Oracle 表 同步 对 象 类 OracleTableDBSynchronizer 充 当 环 境 类 ，DataSynStrategy 充 当 抽 
象 策略 类 ， 其 子 类 IncSynStrategy、DelAndInsSynStrategy 和 TempTableSynStrategy 充 当 具 体 策 略 
类 。 

在 OracleTableDBSynchronizer 中 将 DataSynStrategy 作 为 方 法 synSingleTable() 的 局 部 变量 ， 因 此 
OracleTableDBSynchronizer 与 DataSynStrategy 为 依赖 关系 ， 如 果 为 全 局 变量 ， 则 为 关联 关系 。 


1. 组 合 模式 、 命 令 模 式 和 职责 链 模式 


在 使 用 临时 表 方 式 实 现 表 同 步 时 可 以 定义 一 系列 命令 对 象 ， 这 些 命令 封装 对 数据 库 的 操作 ， 
由 于 有 些 操作 修改 了 数据 库 乡 5 构 ， 因 此 传统 的 JDBC 于 和 入 起 不 到 作用 ， 需 要 自己 实现 操作 
失败 后 的 回 滚 逻 辑 。 此 时 可 以 使 用 命令 模式 进行 设计 ， 在 设计 时 还 可 以 提供 宏 命 令 
MacroCommand， 用 于 将 一 些 具体 执行 数据 库 操作 0 ， 形成 复合 命令 。 类 图 如 图 
9 所 示 (由 于 原始 类 图 比较 复杂 ， 考 虑 到 可 读 性 ， 图 9 进行 了 适当 简化 ， 不 过 简化 了 之 后 还 是 
挺 复杂 的 ) 
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TempT ableSynStrategy 


+ <<Consructor>> TempTableSynStrategy (String table Name, 
Database srcDB, Database desDB) 

+ <<Overide>> processSyn 0 

- generateTempT ableName 0 






* ladCommand :TempTableSynCommand 


add{ :void 
TempTableSynCommand tempTableSynCommand) 

# <<Overide>> Undo 0 :void 

## execute () :void 


lastCommand 


| i 
TempTableSynCommand 


{abdract} 
# previouscommand :TempTableSynCommand 
# nextCommnad :TempTableSynCommand 
+ SetPreviousCommand ( 
TempTableSynCommand preCommand) 
+ execute () 
+ Undo 0 



















- dataSynHelper :DataSynHelper : DataSynHelper 
- database : Database - SrcDB : Database 
- fromTableName : String - desDB : Database 
toTableName :String - fromTableName :String 
<<Constructor>> RenameT ableCommand ( - toTableName _. String 
DataSynHelper dataSynHelper, + <<Constructor> SynTableDataCommand ( 


String fromTableName, DataSynHelper dataSynHelper, 
String toTableName, Database database) String fromTableName, 




































洒 箱 


-void Database desDB) 


# <<Overide>> undo0 
# execute () 


- oldConstraintNames : Stringl] 

- newCondraintNames : String[] 
dataSynHelper : DataSynHelper 
database : Database 
tableName : Sting 
constraintNamePrefix : Sting 


<<ConstructoP> RenameTableConstraintCommand ( 
DataSynHelper dataSynHelper, 
String table Name, Database database) 
<<Overide>> execute () 
<<Overide>> undo0 
queryConstraintNames(String tableName, : 
Database database) 


execute () 









DataSynHelper 


+ renameTable (String fromTableName, :void 
String toT ableName, Database database) 
+ renameCondraintNames(String tableName, :void 
String oldConsraintNameg), 
String newConsraintNamegs], 
Database database) 
+ SnTableData (String fromTable Name, 
String toT ableName, Database srcDB, 
Database dedDB) 
+ dropTable (String table Name, 
Database database) 


DataSynHelper mpl 


+ <<Implement>> renameConsraintNames (StringtableName, :void 
String ol dConstraintNameg], 
String newCon draintName gq], 
Database database) 


+ <<Implement>> renameTable (StringfromT ableName, :void 


String toTableName, Database database) 

+ <<Implement>> SnTableData (String fromTableName, :void 
String toTableName, Database srcDB, 
Database dedDB) 

+ <<Implement>> dropTable (StringtableName, :void 
Database database) 


478 





<<Overide>> undo0 -void String toTableName, Database srcDB, 
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图 9 组 合 模式 、 命 令 模式 和 职责 链 模式 实例 类 图 
《由 于 涉及 到 多 个 模式 的 联 用 ， 此 图 有 点 点 复杂 ) 


在 图 9 中 ，TempTableSynCommand 充 当 抽 象 命令 ，MacroCommand 充 当 宏 命令 类 ， 
RenameTableCommand、SynTableDataCommand 和 RenameTableConstraintCommand 充 当 具 体 命 
令 ，TempTableSynStrategy 充 当 请 求 调用 者 ，DataSynHelper 充 当 请 求 接收 者 ， 在 DataSynHelper 
中 定义 了 辅助 实现 临时 表 方 式 同步 的 一 些 方 法 ， 在 命令 类 中 将 调用 这 些 方 法 。 在 
TempTableSynCommand 中 声明 了 公共 的 execute() 方 法 ， 并 提供 了 回 滚 方 法 undo()， 其 子 类 实现 
具体 的 执行 操作 与 恢复 操作 。DataSynHelper 接 口 声明 了 进行 数据 库 操作 的 方法 ， 在 其 子 类 
DataSynHelperImpl 中 实现 了 这 些 方法 。 


在 TempTableSynCommand 中 还 定义 了 两 个 子 类 型 的 变量 previousCommand、nextCommnad 用 于 
保存 前 一 个 命令 和 后 一 个 命令 ， 其 中 nextCommnad 用 于 在 执行 完 当 前 命令 的 业务 逻辑 后 ， 再 执 
行 下 一 个 命令 的 业务 逻辑 ; 而 previousCommand 用 于 在 出 现 异 常 时 ， 调 用 上 一 个 命令 的 undo0) 
方法 实现 恢复 操作 。 此 时 使 用 了 职责 链 模式 ，nextCommnad.execute() 实 现 正 向 职责 链 ， 而 
previousCommand.undo0 加 上 Java 的 异常 处 理 机 制 实现 反 向 职责 链 。 


MacroCommand 是 宏 命令 ， 其 代码 片段 如 下 所 示 : 


public class MacroCommand extends TempTableSynCommand { 
TempTableSynCommand lastCommand = this; 
public void add(TempTableSynCommand tempTableSynCommand) { 
tempTableSynCommand. setPreviousCommand(lastCommand); 


lastCommand = tempTableSynCcommand; // 创 建 命令 链 
} 
protected void execute() throws Exception { 
} 
protected void undo() throws Exception { 
} 
} 


在 请 求 调用 者 类 TempTableSynStrategy 中 通过 如 下 代码 片段 来 调用 宏 命令 对 象 的 execute() 方 
法 : 


public class TempTableSynStrategy extends DataSynStrategy { 
public String processSyn() { 


// 其 他 代码 省 略 
String tempTableName = generateTempTableName( ); 
String backupTableName = "BAK_" + tempTableName; 


DataSynHelper dataSynHelper = new DataSynHelperImpl1(); 
MacroCommand marcoCommand = new MacroCommand( ) ， 
marcocommand ,add(new RenameTableConstraintCommand(dataSynHel 
marcocommand ,add(new SynTableDataCommand(dataSynHelper, tabl 
marcocommand ,add(new RenameTableCommand(dataSsynHelper, table 
marcocommand ,add(new RenameTableCommand(dataSsynHelper, tempT: 
tryt 

marcoCommand ,execute( ); 

try { 

// 其 他 代码 省 略 
} catch (Exception e) { 
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e.printStackTrace( ); 


} 
} catch (Exception e)t{ 
e.printStackTrace( ); 


} 
// 其 他 代码 省 略 
} 
} 


【本 实例 分 析 到 此 全 部 结束 ， 希 望 能 给 各 位 带 来 帮助 | 】 
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